How to Integrate AI Chatbots in an Online Store

An online store is one of the easier sites to drop a chat widget onto. It is also one of the easiest to leave half-finished. The widget loads on every page, a visitor types a question, an answer comes back. That part is genuinely two lines of code, and most platforms have a slot for it. The hard part is everything that turns that widget into something a store owner would actually want running, and that hard part is the work of integration, not the work of installing.

Most readers arrive at this page wanting to integrate AI chatbots into their existing e-commerce storefront, and the honest answer is that the script tag is the door. Behind it are three more doors, and most storefront owners close after the first. The remaining connections are the catalogue, the order lookup, and the handover to a person. The script tag does none of these on its own.

What follows is the order you actually build them, and what each one asks of the storefront platform underneath.

The three connections, in the order you build them

A storefront chat assistant has to talk to three different systems, and each one needs its own setup. Skipping the catalogue means the assistant guesses at prices and inventory. Skipping the order lookup means every where is my order question is routed to a human. Skipping the handover means a customer explains their problem twice. The script tag does not solve any of these. It only puts the widget on the page.

The rest of this article walks through each of these in the order above, on the four store platforms most readers run today. The pattern is the same on each platform. The endpoints are different.

The three connections

Integration is three connections, not one

Only the first is the script tag. The catalogue and order lookup decide what the answer knows.

1

Catalogue

What is in stock and what it costs

product names SKUs price stock state variant

Installed by a script tag, or Code Injection on Squarespace

2

Order lookup

Where support volume actually sits, and where the permission question starts

order id email match shipment state per-tab permissions

3

Human handover

Decides what a customer repeats when a person takes over

transcript attached routes straight to your team context preserved

Worked example against the published message allowance

Asyntai Standard Plan: $139 per month, 15,000 messages

General questions

9,000

Catalogue answers

6,000

Total against 15,000

15,000

Order lookups sit on top of this and route straight to your team once the permission check passes.

Connection one: the catalogue

The catalogue connection is what stops the assistant inventing products. A customer asks do you have the blue version in a medium and the answer needs to come from the live catalogue, not from the assistant's general knowledge of your storefront. Without a catalogue connection the assistant can answer generic questions about commerce and online shopping, but it cannot answer questions about the specific goods your store sells, which is the only reason a customer is on your site.

There are two common ways to wire this up, and the choice depends on how big your catalogue is and how often it changes.

Periodic sync. The storefront pushes its catalogue to the assistant on a schedule, every hour or every day. The assistant reads from its own copy. This is the simplest setup and works well for catalogues that change a few times a day. Most small storefronts are in this category.

Live fetch. The assistant calls the storefront platform's API on demand for each question. The answer is always current, but every customer question becomes an extra request against the storefront. This matters for stores with frequent stock changes or large catalogues that are too big to sync in full.

On the four store platforms named above, the practical picture is:

• Shopify. The Storefront API and Admin API both expose products, variants and inventory. A periodic sync against the Admin API is the most common setup, because Shopify rate limits the Admin API and a sync keeps you well under those limits. Stock counts come from the same endpoint.
• Magento. The REST and GraphQL APIs both expose the full catalogue and stock. Larger catalogues usually sync rather than fetch live, because live fetching on every question adds load that Magento's hosting can feel.
• WooCommerce. The WooCommerce REST API exposes products and stock, and on a typical self-hosted store the catalogue is small enough that a sync every few minutes is enough. Many stores sync the whole catalogue once an hour and rely on webhooks to push urgent stock changes.
• Squarespace. Squarespace has a Commerce API for products and inventory, but the platform is closer to closed than the other three. A sync is the realistic option, and it works fine for the smaller catalogues Squarespace stores usually carry.

What this connection costs in page weight is the first thing to think about. A chat widget that loads the whole catalogue on every page load will slow the storefront. A sync that loads once on the server and is then read by the widget keeps the storefront fast. For most storefronts the answer is to sync the catalogue into the chat platform and let the widget fetch only what it needs for the current answer. The widget itself should be small; the catalogue should live somewhere the widget can query without pulling the catalogue into the browser on every page view.

What the catalogue connection has to contain

For the assistant to answer the questions a customer actually asks, the catalogue record the assistant reads needs more than a title and a price. It needs the fields the customer asks about, in a form the assistant can reason over.

Most platforms expose these fields through their standard API. The work is deciding which fields to sync and how often, and that is a catalogue-size question more than a platform question. A 200-product store syncs the whole catalogue every hour without thinking about it. A 50,000-product store has to think. The thinking is about what to sync, how often, and what to leave out.

Connection two: the order lookup

This is where the real support volume sits, and where the permission question starts. In most online stores, the single largest category of customer question is some flavour of where is my order. Refund status, dispatch date, delivery window, returns, address changes: the same handful of questions, asked over and over. An assistant that cannot answer these is a wrapper around a search box, not a useful piece of support automation.

To answer any of these the assistant has to read a specific order belonging to a specific customer. That means two things the catalogue connection does not: it has to know who is asking, and it has to be allowed to see their order. Both come with rules, and the rules are why this connection is harder than the catalogue.

Identifying the customer. The simplest setup is to ask for an order number and the email address on the order. The assistant looks the order up, checks the email matches, and reports back. This is the minimum, and it is what most storefronts start with.

Authenticating the customer. Stronger setups use a one-time code sent to the email on the order, or a login link, before any order data is read. This stops a stranger who guesses an order number from reading someone else's delivery address. For most stores this is overkill on day one. For stores handling high-value goods it is not.

Permission scope. The assistant should read only the orders belonging to the customer in front of it, and it should not surface data the customer does not need. A where is my order question returns a status. It does not return the payment method, the internal notes on the order, or the previous orders.

On the four named platforms the order endpoint is:

• Shopify. The Admin API's Orders endpoint, scoped by customer email and order number. Most stores gate this with a one-time code so a stranger cannot read an order they have guessed the number for.
• Magento. The Sales API returns orders for the authenticated customer. The cleanest setup ties the chat session to a Magento customer token, so the assistant reads only orders belonging to the customer who has signed in.
• WooCommerce. The Orders endpoint on the WooCommerce REST API, with the same customer-scoping logic. Most stores use an order number plus an email match, because most WooCommerce stores do not require a customer login to place an order.
• Squarespace. The Orders API exposes orders by ID, but the customer's email has to be checked against the order before any data is returned. This is the same gating pattern as Shopify, on a smaller surface.

What this connection costs in requests is the second thing to think about. Every where is my order question becomes a fetch against the storefront's order endpoint. If your storefront runs on a platform with strict rate limits (Shopify's Admin API in particular) a sudden spike in where is my order traffic can hit those limits. A chat platform that caches the most recent order for a few minutes per session is kinder to the storefront than one that fetches on every question.

How many of your tickets are order lookups

Order lookups are the volume that decides whether the integration is worth doing at all. If half your tickets are order status, and the assistant handles them, your team's queue halves. If only a fifth of your tickets are order status, the integration is still useful but the case for it is weaker.

That is the number that decides whether the integration is worth the build. It is a function of your current volume and the share of it that is order status, and both of those are inputs you measure on your own storefront today, not facts about the market. Run the same maths with your own numbers and the case for the integration either holds or it does not.

Connection three: the human handover

The handover is the connection most readers skip, and the one customers feel most sharply when it is missing. When the assistant decides a person should take over, the conversation has to land in your team's queue with the history attached. If it lands without the history, the customer starts again, and that is the moment the chat stops being a help and starts being an obstacle.

A working handover has three pieces:

• A clear hand-off rule. The assistant has to know when to hand over. The most useful triggers are: the customer asks for a human, the customer's question matches a topic the assistant is configured not to answer (refunds above a threshold, complaints, account closure), or the assistant has tried and failed to answer twice.
• A queue destination. The conversation lands in the place your team already works. For most online stores that is a shared inbox, a helpdesk, or a Slack channel. The handover has to drop the conversation into the right place, with the right urgency flag.
• A full transcript. The person picking up the conversation needs to see what the customer asked, what the assistant answered, and any data the assistant already pulled. Without the transcript the customer repeats themselves. With it, the conversation continues.

What this connection costs in setup is mostly configuration. The technical work is the smallest part. The harder work is deciding the trigger rules and the queue routing, because those are the rules that decide what a customer experiences when something goes wrong.

The handover rule most stores get wrong

The most common mistake is to hand over too late. The assistant tries three times to answer, fails three times, then offers the customer a link to email support. By that point the customer is frustrated and the email arrives without context. The customer's first message in the new channel reads like a brand new ticket, and the team has no idea what was already tried.

A better rule is to hand over earlier on the topics your team has decided are sensitive. Refunds above a set value, complaints, anything involving a legal question, anything the customer has asked about twice: hand these over at the first recognition, not the third failure. The cost of a slightly higher handover rate is paid back many times by a shorter resolution time when the person takes over.

The four platforms, side by side

The three connections look different on each platform. The table below is for orientation, not for shopping. The point is that each storefront has its own API surface and its own rate limits, and the integration has to be designed against those, not against a generic online store.

The columns are the three connections, not a list of features. A platform with a richer catalogue API does not necessarily make the integration easier; it makes the data design harder. A platform with a closed order API makes authentication harder, because there is less to hook into. The shape of the integration tracks the shape of the API underneath.

What goes wrong on each platform

Each platform has a failure mode that is specific to it, and a reader who runs that platform should know what to watch for.

Shopify. The Admin API is rate-limited, and a chat integration that polls for order status on every question can hit that limit during a busy afternoon. Cache the order data in the chat session for a few minutes, and batch the syncs.

Magento. Magento hosting is often the bottleneck before the API is. A live-fetch integration on a busy catalogue will load the database harder than the storefront itself does. Sync where you can, and fetch only when the question genuinely needs live data.

WooCommerce. WooCommerce stores vary wildly in hosting. A well-hosted store can take the load; a poorly hosted one cannot. The integration should be tested against the store's own hosting, not against an assumption.

Squarespace. Squarespace's Commerce API is narrower than the other three. Anything the API does not expose, the integration cannot answer, and customers notice the gap. Decide before launch which questions are in scope.

Working the numbers against a named plan

The integration work is fixed-cost: the build, the catalogue sync, the order hook, the handover rule. After that the running cost is the message allowance. The arithmetic below uses a volume you supply, against the published allowance of the Starter plan.

This is the test that matters before launch. Pick a message volume you can defend (a slow month, a busy month, an average month), compare it to the published allowance of the plan you intend to buy, and decide whether the plan holds. If the volume is over the allowance, the next self-serve plan is the answer; if the volume is well over that, enterprise is a signed order form with a negotiated allowance.

The same arithmetic at a lower volume tells the other half of the story. The Starter plan holds up to 800 messages a month. A storefront doing fewer than that sits comfortably inside it, and the build cost is the only number that matters at that scale.

The checklist before you turn it on

Five things to confirm on a test storefront before the widget goes live on the real one.

1. The catalogue sync matches the live storefront. Pick three products and confirm the assistant's price, stock and variants match the storefront exactly. If they do not, the sync is not finished.
2. An order lookup returns the right order to the right customer. Use two test accounts. Each asks about its own order. Each gets only its own data back. If either sees the other's order, the gating is wrong.
3. The handover carries the transcript. Trigger a handover manually and confirm the transcript lands in the queue, with the customer's last message and any data the assistant already pulled. If the transcript is missing, the handover is not finished.
4. The widget does not slow the storefront. Check the storefront's page weight before and after the widget is installed. The widget is the difference, and the difference should be small.
5. The rate limits hold. Simulate a busy hour of where is my order traffic and confirm the storefront's API does not throttle. If it throttles, the caching strategy needs another pass.

These are the same five checks, in the same order, on every storefront. The platform changes the endpoint. The checks do not.

What the integration is, and what it is not

The script tag is the part of the integration most readers come to this page for. It is the smallest part. A widget that loads on the storefront, with no catalogue, no order lookup, and no handover, answers general questions and nothing else. It does not know what the store sells, it cannot tell a customer where their order is, and it does not connect to the team that handles the questions it cannot answer.

The catalogue connection is what makes the assistant useful on product questions. The order lookup is what makes it useful on the questions that drive your support volume. The handover is what makes it part of your team instead of a separate inbox customers have to repeat themselves into.

All three connections together is what turns a widget into something an online store actually needs. The script tag is the door. The three connections are the rooms behind it.