Connect a Support Chatbot to Shopify Order Status (and WooCommerce)

"Where is my order?" is the question every online store answers more than any other, and it is the one question a chatbot trained on your help pages cannot answer, because the answer isn't on a page. It lives in Shopify or WooCommerce, changes by the hour, and is different for every customer. Connecting the AI support agent to the store is the fix: it looks the order up live, at the moment the customer asks, and answers from the real record.

This guide is for store owners and the developers who help them. It covers what a "where is my order" chatbot saves, which data the agent should and should not see, what to do when you cannot verify who is asking, the exact Shopify and WooCommerce setup steps, and how to test it before customers do. The product steps use PepoChat, whose Shopify and WooCommerce actions come prebuilt; the platform steps apply to any tool.

What does "where is my order" cost a store?

A WISMO ticket (support shorthand for "where is my order") is a conversation whose only purpose is to relay information the store already has. Somebody opens the order in the admin, copies the tracking number, and pastes it back. It takes a few minutes, it is never interesting, and the customer usually asks more than once per shipment: after checkout, after the shipping email, and again when the carrier's estimate slips.

The cost is the shape of the volume rather than any single ticket. These questions arrive in bursts that track your shipping calendar and promotions, so they land when the team is busiest, and an answer that arrives the next morning is often worthless. Every minute spent copying tracking numbers is a minute not spent on damaged goods and returns.

A chatbot that can read the order makes the lookup free and instant, at 2 a.m. and on Black Friday alike. It doesn't need to be clever; it needs to be connected, careful with data, and honest when the record says nothing new.

What can a chatbot Shopify order status lookup actually see?

An order record contains far more than a customer needs for "where is it". The question is not what the API exposes but what the agent should be allowed to repeat. Split the fields into three groups.

Safe to show to the verified customer. The order number, the date, the order status (open, closed, cancelled), the fulfilment status, the item names and quantities, the carrier, the tracking number and tracking link, and the city or country the parcel is going to. Shopify's REST Order resource documents fulfillment_status values of fulfilled, partial, restocked or empty, and financial_status values such as pending, authorized, paid, partially_refunded, refunded and voided; the fulfilments array carries the tracking_number and tracking_company. WooCommerce exposes an equivalent status field whose values are listed in the WooCommerce order statuses documentation.

Useful to the agent, but summarise rather than quote. Payment status lets the agent explain that an unpaid or failed order hasn't shipped for a reason, but it should say "payment is still pending" rather than reading out refund amounts. The shipping address is similar: "it's going to the address in Leeds" reassures a customer without printing a street address into a chat window that might be on a shared screen.

Never expose. Neither platform returns card numbers through its order API, but there is still plenty to keep out: phone number, billing address, internal notes and tags, discount codes, and any other customer's data. The mechanism for this is an allow-list, a fixed list of response fields the AI is permitted to read; anything not on it is stripped before the model sees the response, so it can't be leaked by a clever prompt.

Should the chatbot verify the customer before showing order details?

Yes, and this is the step people skip when they wire a store up in an afternoon. Order numbers count upwards, so if your bot answers "what's the status of order 1042?" for anyone who asks, a stranger can walk through your order book one number at a time and learn who bought what and where it went. That is true of Shopify's order names and WooCommerce's order IDs alike.

The usual fix is to require both the order number and the email address on the order. That is better than nothing, but an email address is not a secret, and typing one into a chat proves nothing. The stronger option is to verify the email: send a code to that address and only continue once the visitor types it back. Now "orders for [email protected]" is answered to Jane, not to whoever knows Jane's address.

PepoChat does not do this for order lookups. Chats start anonymous unless you switch on lead capture, which can ask for details before the first message. A visitor can verify their email in the widget with a 6-digit one-time code, which expires after 10 minutes, allows 5 attempts and has a 60-second resend cooldown, and is then a verified visitor for the rest of the 24-hour session. That unlocks meeting memory if you have enabled it, bookings with the verified name and email, and an emailed transcript. It does not gate the Shopify or WooCommerce actions: they run on whatever order number or email the visitor types, and the agent is never told whether the visitor verified.

So design every lookup for the stranger, not the customer. Judge an action by what someone who guessed an order number, or knows a customer's email, could learn from it, and keep its response fields short. If a lookup cannot confirm who is asking, leave the items, carrier, tracking and destination from the first group out, and keep to the order number, the date and the order's payment and fulfilment status. Those are exactly the four fields PepoChat's Shopify action reads. A line in an action's "when to use" text such as "Only use this after the visitor has verified their email" makes the agent ask for the code, but the agent cannot confirm the visitor finished, so treat it as a speed bump, not a lock.

How do you connect Shopify order status to a chatbot?

Shopify's route to an API credential for your own store changed at the start of 2026. Custom apps used to be created inside the store admin, and existing ones still work, but Shopify's help centre says new ones can no longer be created there; new integrations go through the Dev Dashboard, Shopify's separate console for building and managing apps. The steps below follow Shopify's installing and setting up apps guide.

Step 1: Create a custom app in the Dev Dashboard

In your Shopify admin, open Settings → Apps, choose Develop apps, then Build apps in Dev Dashboard. There, select Create app, choose to start from the Dev Dashboard rather than the CLI, name it "Support chatbot", and create it. Store owners can do this directly; staff accounts need the App development → Develop permission first.

Step 2: Give it the read_orders scope

Open the app's Versions tab and create a version. This is where you set the app's access scopes, the list of data the app is allowed to touch. Add read_orders and nothing else: the chatbot reads orders and never writes them, and a token that can't modify anything costs you less if it leaks. Shopify also asks for an App URL; the app never loads inside Shopify, so PepoChat's setup screen suggests https://app.pepochat.com as a placeholder, with Embed app in Shopify admin turned off. Release the version.

Shopify's access scopes reference contains a detail that surprises almost everyone: read_orders covers orders created within the last 60 days. Older orders are invisible unless you also request read_all_orders, which needs Shopify's approval. For a "where is my order" bot that is usually fine, but it explains the "order not found" reports you would otherwise get for an old order.

Step 3: Install the app and copy its client credentials

From the app's Home page, choose Install app, pick your store and confirm. The store must belong to the same Shopify organization as the app. Don't pick a distribution method: it isn't needed and can't be changed later. Then open the app's Settings page and copy the Client ID and Client secret.

Those two values are not a token. They are what Shopify's client credentials grant exchanges for an Admin API access token, and each token expires after 24 hours, so whatever holds them has to request a new one every day. PepoChat does that itself and renews the token automatically, so you never copy or rotate one. If you have a legacy admin-created custom app from before 2026, its shpat_ token still works, but PepoChat's Shopify integration does not take one; you can use it in a custom action with an X-Shopify-Access-Token header instead.

Step 4: Paste the credential into the chatbot

In PepoChat, open Integrations, choose Shopify, and enter your store domain (your-store.myshopify.com, or paste your admin URL), the Client ID and the Client secret, then tick Check order status and click Add actions. The secret is encrypted with AES-256-GCM and cannot be read back from the dashboard afterwards, so keep your own copy in a password manager.

How do you connect WooCommerce orders to a chatbot?

WooCommerce ships its REST API inside the plugin, so there is no app to create; you generate a key pair and point the chatbot at your own domain. The official reference is the WooCommerce REST API documentation.

Step 1: Check permalinks and HTTPS

The API only works with pretty permalinks. Go to Settings → Permalinks in WordPress and select anything other than "Plain"; WooCommerce's docs are blunt that default permalinks will not work. The site must also be served over HTTPS, because the key pair is sent as HTTP Basic Auth, which is only safe on an encrypted connection.

Step 2: Generate a REST API key with Read permission

Go to WooCommerce → Settings → Advanced → REST API and click Add key. Give it a description, pick a user (ideally a dedicated shop manager account rather than the admin), set Permissions to Read, and generate it. WordPress shows the Consumer key and Consumer secret once; copy both immediately, because the secret is not retrievable later.

Read permission covers the chatbot's two jobs, one order by number and a customer's recent orders, and guarantees the bot can never change an order however hard someone tries to talk it into one.

Step 3: Paste the key pair into the chatbot

In PepoChat, open Integrations, choose WooCommerce, enter your store domain, consumer key and secret, and tick the actions you want. Under the hood one action calls GET /wp-json/wc/v3/orders/<id> for a single order and the other GET /wp-json/wc/v3/orders?search=<email>&per_page=3 for lookups by email, authenticating with the consumer key as the username and the secret as the password, as the WooCommerce docs describe.

Step 4: Fix the Authorization header if the test fails

The most common WooCommerce failure is a 401 with the message "Consumer key is missing" even though the key is correct. WooCommerce's docs explain that some servers don't pass the Authorization header through to PHP, so WooCommerce never sees the credentials. This is typical of Apache running PHP as CGI or FastCGI (PHP-FPM), as many shared hosts do.

The fix is to tell Apache to forward the header. Add this line to .htaccess in your WordPress root, above the WordPress rewrite rules:

# .htaccess — forward the Authorization header to PHP-FPM / CGI
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

That line, and the nginx equivalent (fastcgi_pass_header Authorization; in the PHP location block), are explained in a widely referenced write-up on the WooCommerce 401 problem. If you cannot edit server configuration, WooCommerce also accepts consumer_key and consumer_secret as query parameters over HTTPS, but treat that as a last resort, because query strings end up in server logs.

How do the prebuilt order actions work?

An action, in PepoChat's vocabulary, is a tool the AI support agent can call during a conversation: a templated HTTPS request with typed inputs, plus rules about what comes back. The Shopify and WooCommerce actions come prebuilt and editable, like the other integrations on the use cases page.

Order by number. The agent extracts the order number from the conversation and passes it as a typed input. Both prebuilt inputs carry a fixed format check, digits only and at most 10 of them, so the agent must send 1042 rather than #1042, and letters or symbols are rejected before any request goes out. Shopify's action sends the number as a name: filter to the GraphQL Admin API's orders query; WooCommerce's fetches /orders/<id>. The response is filtered through the action's response-field allow-list, and only the surviving fields reach the model: the order name, date, payment status and fulfilment status on Shopify, and the status, dates, total, currency and payment method on WooCommerce. Neither returns a carrier, tracking number or tracking link, so the reply is a plain-language status, not the parcel's whereabouts.

Orders by email. Only WooCommerce has one. For a customer who has lost their order number, "Find WooCommerce orders by email" passes an email address to the orders list endpoint's search parameter and returns up to three orders with their number, status, date and total. The address is whatever the visitor types in the chat; the action does not check that it is theirs. PepoChat's Shopify integration has no email lookup, so a Shopify customer without the number needs the confirmation email or a person on your team.

Guardrails you don't have to configure. Every outbound call is HTTPS-only; private and internal hosts are refused (checked lexically and via DNS-over-HTTPS resolution), redirects aren't followed, requests time out after 10 seconds, response sizes are capped, and customer inputs are escaped for the context they land in. A malicious "order number" becomes a sanitised parameter, not an injection.

One honest limit. Action execution is at-least-once, so a call can in rare cases run twice. That is harmless for order lookups, which are reads, and it is why lookups and status checks belong in actions but refunds and payments do not. If the prebuilt actions don't cover what you need, for example tracking numbers, which neither returns, you can build a custom action: any HTTPS endpoint with a templated URL, headers and body, typed inputs and your own allow-list. It runs on whatever the visitor types too, so the same stranger test applies.

How should the agent handle the questions around order status?

Connecting the data is half the job. The other half is the conversation around it, and most of that comes from your knowledge base rather than the API.

Shipping policy questions ("how long does delivery take to Ireland?") should be answered from your shipping page, imported as a knowledge source, not from the order; the training guide shows how.

"It says delivered but I don't have it" is where a bot must stop being helpful and hand over, because the record can't tell you whether the parcel is with a neighbour. The agent should confirm what the record says and escalate to the team inbox, which PepoChat does whenever it finds nothing useful or the visitor asks for a person. The human handoff post covers what that should look like.

Cancellations and address changes are writes, not reads. With a Read-only credential the agent can't perform them, which is the right default; it collects the request and hands it to the inbox. The wider list of what an ecommerce agent should handle is in the 12 ecommerce chatbot questions.

How do you test the order-status flow before customers use it?

Run these on a staging store, or on your live store with your own test orders.

1. Lookup by number. Ask for an order you placed, by its number, and check the reply gives its status and date and nothing from the "never expose" column.
2. The stranger test. Open the widget in a private window, don't verify, and ask about one of your test orders by number. The agent answers, because order lookups are not gated by verification, so read the reply as if a stranger had guessed the number: it should tell them nothing you would mind them knowing.
3. A neighbouring number. Ask for the order one above or below a real one, the way someone walking your order book would. On WooCommerce the reply includes the total; if that matters, switch off the number lookup or remove total from its field list.
4. Orders by email (WooCommerce). Ask "what have I ordered recently?" and give a test customer's email. You should get at most three orders with their number, status, date and total, and an address with no orders should get a plain "nothing found", not a guess.
5. An old order. On Shopify, ask for an order older than 60 days and confirm the agent says it can't see it rather than claiming it doesn't exist.
6. A nonsense order number. Type letters or a script tag and confirm the input validation rejects it.
7. Handoff. Say "it says delivered but it's not here" and confirm the conversation lands in the team inbox as escalated.

Then watch the analytics. PepoChat auto-labels conversation topics in weekly buckets, so an "order status" spike after a promotion shows the integration carrying the load, and an escalation spike shows which case it isn't.

Troubleshooting

What to do next

Get the widget live if it isn't already using the one-script-tag install guide, then connect your store with the steps above and run the seven tests. If you are still choosing a tool, the best AI chatbot for Shopify comparison puts Shopify Inbox, Gorgias, Tidio and others side by side on this same lookup. Import your shipping and returns pages as knowledge sources so the agent can answer the policy questions around an order, not just the status. Actions and email verification are included with every feature on the free plan; the pricing page lists the monthly limits, and you can start a free workspace without a card.