Connecting a Shopify catalogue to an AI support agent

Two different jobs, two different levels of access. Reading your catalogue — names, prices, stock — needs no credentials at all on Shopify, because the storefront already publishes it. Reading an order needs an Admin API token. Conflating them is why setup guides ask for far more access than the job requires.

Why the catalogue has to be live

The tempting shortcut is to paste product information into the agent's knowledge base as text. It works for a week. Then a price changes, something sells out, and the agent confidently quotes last month's number to someone about to buy.

A wrong price is worse than "I don't know" in a way that is easy to underestimate. It is a support ticket, a trust problem, and in some jurisdictions an advertised price you may be expected to honour. Stale catalogue data does not fail loudly; it fails politely and specifically.

So the catalogue needs to be read from the store, on a schedule, rather than described to the agent once.

What Shopify gives you without any keys

Every Shopify storefront publishes /products.json. It is public, it paginates, and it carries what an agent needs to answer accurately:

• Product name, description and SKU
• Price, and the sale price where one applies
• Stock status, and quantity where the store exposes it
• Categories, the product URL and the image

That is the entire catalogue import. No app to install, no private app to create, no theme edit, no scopes to review. If you can open yourstore.com/products.json in a browser, an agent can read your catalogue.

WooCommerce is the same shape with more variation. The Store API at /wp-json/wc/store/v1/products is public and preferred. Where a store has it disabled — common enough — the REST API works with a consumer key and secret, and past that the product pages themselves can be read directly. Thredo tries them in that order, so the most common case needs nothing from you.

Re-syncing, and the part that is easy to get wrong

An import is not a one-off. Prices move, products get discontinued, and a catalogue that was right in March is a liability in August.

Re-syncing has to do two things. It has to update existing products in place rather than creating duplicates — matching on the store's own product id, not the name, because names get edited. And it has to remove products that have vanished from the store since the last sync. Miss the second and your agent will happily sell something you delisted.

Order lookup is a different problem

Orders are not public, and should not be. Reading them needs an Admin API access token with read access to orders, from a custom app in your Shopify admin.

With that in place the agent can answer the question that actually dominates your queue: payment status, fulfilment status, order total. Where-is-my-order is up to 40% of ecommerce support volume, and it is answerable from exactly those three fields.

The check most setups skip

Here is the failure worth designing against before you turn this on. Order lookup usually works by order number. Order numbers are sequential. A customer who has #1043 can reasonably guess that #1042 exists.

If your agent looks up whatever number it is given and reads back the result, it will tell one customer about another customer's order. Nothing errors. Nobody notices until somebody does.

So an order lookup needs an ownership check, and on a messaging channel you already have what you need for one:

• On WhatsApp, SMS or Telegram, you know the sender's phone number. Match it against the order's phone or the customer record before reading anything back.
• On web chat and email, you have no verified identity, so ask for a second factor the real customer has and a guesser does not — the email address on the order, or the delivery postcode.
• Fail closed. If the check does not pass, hand to a human rather than reading out a partial answer. "I can't confirm that one — let me get someone" costs a handover. The alternative costs a disclosure.

This is also a policy question, not only a courtesy one. Meta's Business Messaging Policy is explicit that you may not share information from one customer's chat with another, and that data obtained about a person may only be used as reasonably necessary to support messaging with that person.

What good looks like

• Catalogue on a schedule, read from the store, with removals honoured.
• Prices quoted from the import, never from the knowledge base.
• Order lookup behind an ownership check that fails closed.
• The Admin token scoped to reads — an agent answering questions has no reason to be able to change anything.
• A human one message away, which on WhatsApp is not optional: automation inside the 24-hour window is permitted on the condition that a clear escalation path exists.

Where it still needs a person

Catalogue and order data answer "what is it" and "where is it". They do not answer "should we make an exception for me", which is most of what is left once the easy volume is handled. That is the right division: the agent takes the repetitive 40%, and your team gets the conversations that need judgement, with the order already on screen.

Common questions

Published 11 August 2026. Endpoint paths are Shopify’s and WooCommerce’s current public APIs; both platforms change these from time to time, so verify against their documentation before building against them.