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, how to 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 jane@example.com" is answered to Jane, not to whoever knows Jane's address.

PepoChat's widget does this without a pre-chat form. Chats start anonymous, and 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. Once verified, the visitor is a verified visitor for the rest of the session, and the Shopify or WooCommerce action can use that confirmed address to find their orders.

Two practical notes. Verification should be once per session, not per question; asking for a code every time trains customers to email instead. And the agent should never accept a merely typed email as proof.

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. 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 on your store and get a token

From the app's Home page, choose Install app, pick your store and confirm. Installing is what turns the scopes you configured into an offline Admin API access token for that store — a long-lived shpat_… credential that a support integration can hold and reuse. It is shown once; copy it into a password manager straight away, because if it is lost Shopify's guidance is to uninstall and reinstall the app to mint a new one.

Two things to avoid. Do not paste the app's Client ID and Client secret into the chatbot: those are for the client credentials grant, which returns tokens that expire after 24 hours and must be re-requested by code, so a static integration configured with one stops working the next day. And if you have a legacy admin-created custom app from before 2026, its existing shpat_ token still works and you can reuse it instead of creating a new app.

Step 4: Paste the credential into the chatbot

In PepoChat, open App Integrations, choose Shopify, and enter your store domain (your-store.myshopify.com) and the shpat_ Admin API access token from the step above. The credential is encrypted with AES-256-GCM per organisation 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's Actions page, choose WooCommerce and enter your store URL, consumer key and secret. Under the hood the action calls GET /wp-json/wc/v3/orders/<id> for a single order and GET /wp-json/wc/v3/orders?search=… for lookups, 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. Inputs can carry an optional format regex, so you can insist that a number looks like #1234 (Shopify) or a plain integer (WooCommerce) before any request goes out. The response is filtered through the allow-list you configure, and only the surviving fields reach the model, which writes a plain-language reply with the status, carrier and tracking link.

Orders by email. For a customer who has lost their order number, the action lists recent orders for an email address. Shopify's Admin API order search supports filtering by the email on the order; WooCommerce uses the orders list endpoint's search parameter. The email should come from the verified visitor, not from the chat text.

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 match your store, for example because a shipping plugin stores tracking in custom metadata, you can build a custom action: any HTTPS endpoint with a templated URL, headers and body, typed inputs and your own allow-list.

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. Verified lookup by number. Verify your own email in the widget, ask for an order you placed, and check the reply contains the status and tracking and nothing from the "never expose" column.
2. Wrong-email lookup. Verify as one address and ask for an order placed under a different one. The agent must refuse, not reveal.
3. Unverified lookup. In a fresh anonymous session, ask "where is order 1042?". The agent should ask you to verify first.
4. Orders by email. Verify and ask "what have I ordered recently?". You should get a short list, not the whole order book.
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. 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.