AI Chatbot Shopify Integration Built on the Right APIs and Webhooks

Shopify gives a chatbot two APIs, and each has a different job

Most chatbot vendors describe their Shopify connection as a single switch. Underneath, a well-built integration talks to Shopify through two separate interfaces with different credentials, different permissions and different failure modes. Getting that split right is the first engineering decision, and it sets the ceiling on what the bot can safely do.

The Admin API is the back-office interface. It can read the full catalog including unpublished products, inventory by location, orders, customers, fulfillments and refunds. Shopify now treats its GraphQL Admin API as the primary interface and has marked the older REST Admin API as legacy, so new integrations should be written against GraphQL. Admin access is powerful, which is exactly why it must never be reachable from a shopper’s browser.

The Storefront API is the customer-facing interface. It exposes what a visitor could see anyway, such as published products, prices in the shopper’s market and carts, and it is designed to be called with a lower-privilege token. On an Online Store theme, the theme’s own cart endpoints also let the widget add items to the cart the shopper already has open.

Treat the table as a default that bends to your store. A store with a few dozen products and no subscriptions may skip the search index and query live; a store with thousands of variants almost always needs one.

Requesting the narrowest access scopes that still work

Every Shopify app, including a custom app built only for your store, declares access scopes such as read_products, read_inventory, read_orders and their write counterparts. Shopify shows the store owner exactly which scopes are requested at install. We request the smallest set the agreed features need and document why each one is present.

Three scope details regularly catch teams out:

• Order history depth. By default an app can read only orders from the last 60 days. Older orders require Shopify’s read_all_orders permission, which has to be requested separately. For a support bot, recent orders cover most status questions, and anything older is better routed to a person anyway.
• Customer data. Shopify places personal details such as names, emails, phone numbers and street addresses in a protected customer data category, with added obligations for apps that use them, especially apps listed publicly. If the bot only needs to confirm that an email matches an order, it does not need broad customer read access; the order itself carries the email.
• Write scopes. Permissions like write_orders or write_discounts turn a helpful assistant into something that can change money. We leave them out unless a specific, reviewed feature needs one, such as letting a shopper correct a shipping address before fulfillment, and even then the change runs through server-side rules, not the model’s judgment.

How a custom app is created depends on your plan and on Shopify’s current developer tooling, which Shopify has reorganized more than once. We confirm the present route during scoping. The principle does not change: you install the app, you can see its permissions, and uninstalling it revokes access immediately. Our service subscribes to the app/uninstalled webhook so it notices and stops calling Shopify at once.

Keeping the bot’s product knowledge in step with the store

A chatbot that advertises a sale after it ended, or recommends a discontinued colorway, damages trust faster than having no bot. The cause is nearly always a stale copy of the catalog. We build the sync in three layers.

1. Initial load with a bulk operation. Rather than paging through thousands of products one request at a time, the Admin API can run a bulk query in the background and return a downloadable JSONL file of products, variants, collections and the metafields we select. We transform that file into the chatbot’s search index: one record per product with its variants, options, publication status and the plain-language description shoppers actually read.
2. Incremental updates by webhook. We subscribe to product create, update and delete events, plus inventory level changes where stock affects answers. Each event rewrites one record instead of rebuilding everything, so an edit reaches the bot shortly after Shopify delivers the event.
3. Nightly reconciliation. Webhook delivery is dependable but not guaranteed; deliveries fail and subscriptions can lapse. A scheduled job compares update timestamps in Shopify against the index, repairs any drift and reports how many records it corrected. A rising correction count is our early warning that webhook delivery needs attention.

Two rules sit on top of the sync. Availability and price are re-checked live at the moment the bot quotes them, even when the index holds a value, because those are the facts shoppers act on. And products that are unpublished from the Online Store channel, or reserved for wholesale, are filtered out during indexing rather than left for the language model to ignore. What never enters the index can never be mentioned.

Order status answers that never expose someone else’s order

“Where is my order?” is the most common question a store chatbot receives and the riskiest one to answer carelessly. Order numbers are sequential and trivial to guess. If the bot returns an item list or a delivery address to anyone who types #1052, it has become a data leak with a friendly tone.

We use one of three verification patterns, chosen with you:

• Order number plus contact detail. Our server fetches the order by its name and compares the email or phone on the order with what the shopper typed, after normalizing case and formatting. Only a match unlocks status, carrier and tracking. Several failed attempts from one session pause further lookups.
• Signed-in customers. When the shopper is logged in to your store’s customer account, the widget passes a verified session to our server, and the bot lists that customer’s recent orders without asking for anything.
• Emailed confirmation link. For anything sensitive, such as a request to change the delivery address, the bot sends a short-lived link to the email on the order and continues only after it is opened.

Even after verification the bot shares the minimum: fulfillment status, carrier, tracking number and whatever delivery estimate the carrier has supplied to Shopify. It does not read back full addresses or payment details, and it does not invent a delivery date when none exists. Every Shopify order has its own status page, and the bot links to it as the authoritative view.

What happens to a Shopify webhook after it reaches our server

Webhooks drive the catalog sync, order notifications and uninstall handling, so the receiving endpoint gets the same care as the conversation layer. Each delivery passes through a fixed sequence:

1. Verify the HMAC signature Shopify sends in the X-Shopify-Hmac-Sha256 header, computed over the raw request body with the app’s secret. Anything that fails is dropped and logged.
2. Record the delivery’s webhook ID. Shopify can send the same event more than once, so a repeated ID is acknowledged and ignored rather than applied twice.
3. Place the payload on a queue and respond with success immediately. Shopify expects a quick answer, and slow handlers are treated as failed deliveries and retried.
4. Process from the queue, fetching fresh data from the Admin API when the payload might be outdated. Events can arrive out of order, so the handler compares the resource’s updated timestamp before overwriting anything newer.

Shopify retries failed deliveries for a limited window and can remove a subscription after sustained failures. Our monitoring alerts on a climbing failure rate well before that point, and the nightly reconciliation fills any gap left while an endpoint was down.

Query cost, throttling and Shopify’s quarterly API versions

Shopify’s GraphQL Admin API does not simply count requests. Each query has a calculated cost based on how much data it asks for, and an app draws from a bucket of cost points that refills at a fixed rate each second, with larger allowances on higher Shopify plans. A chatbot that runs an expensive nested query for every message can drain that bucket during a traffic spike, and then even simple order lookups start failing.

We deal with this in the design rather than relying on retries:

• Queries ask only for the fields the answer needs. A stock check does not pull descriptions and image URLs.
• Product questions are served from the index, so a busy sale weekend does not multiply Admin API calls.
• The client reads the throttle status Shopify returns with each response and slows down before the bucket empties, then backs off and retries if it is throttled anyway.
• If Shopify stays unavailable, the bot admits the lookup is unavailable at the moment and invites the shopper to leave an email for a follow-up. It never fills the gap with a guess.

Versioning is the other standing obligation. Shopify publishes a new API version every quarter, named by year and month, and supports each one for at least twelve months. Our integration pins an explicit version, and ongoing maintenance includes testing against newer versions before the pinned one is retired, so a deprecation notice never turns into a silent breakage.

Where the chat widget can live on a Shopify storefront

Putting a widget on every page sounds trivial, but Shopify offers several routes with very different maintenance costs.

For most themes we recommend the app embed, because your theme files stay untouched. Checkout is deliberately locked down by Shopify for security and speed, so the bot usually lives on product, collection, cart and order-status pages, and pre-purchase doubts are resolved before the shopper reaches the payment step.

Page speed matters on a storefront. The widget script loads after the main content, never blocks rendering, and the heavier chat interface downloads only when a shopper actually opens it.

EVOTECH’s build sequence, from scoping call to live store

1. Scoping call. Free of charge, over phone or video. We review catalog size, the apps you already run for reviews, subscriptions or returns, the questions that dominate your support inbox, and whether you use an Online Store theme or a headless front end.
2. Written scope. A fixed-scope written quote naming every chatbot action, the Shopify scopes each needs, the order verification method, and what is deliberately excluded.
3. Development store build. We build against a Shopify development store stocked with representative products, so nothing touches real customers while the conversation logic takes shape.
4. Adversarial testing. We try to break it: guessed order numbers, prompts fishing for discounts, a product unpublished seconds earlier, a webhook replayed twice, a throttled API. Each case has its expected outcome written down before the test runs.
5. Install on your store. You install the app and approve its scopes yourself. The widget ships switched off, the sync runs, and we compare the index against your live catalog before turning it on.
6. Review and tune. After launch we go through unanswered questions and failed lookups with you, then adjust the index, the wording and the handoff rules.

Shopify is often one piece of a larger stack. If subscriptions or invoices run through Stripe rather than Shopify Payments, our Stripe chatbot integration page covers that side, and WordPress stores follow the WooCommerce integration pattern instead. Wider AI integration work, such as feeding chat outcomes into a CRM, is scoped the same way. For context on who builds it: our company has been doing web and software work for over twenty years, Google reviewers rate it 5.0, and its Houston-area staff handles Shopify projects entirely remotely, coast to coast.

Related services

Frequently asked questions