A chatbot can check WooCommerce order status, and on WordPress there are two ways to wire it: call the WooCommerce REST API, whose orders endpoint returns an order’s status, items and totals, or use a plugin that calls WooCommerce functions directly inside the site. The part that decides whether it is a good feature or a data leak is identity. The bot must verify who is asking before it looks anything up, through a logged-in session or an order number matched with the billing email, and return only that customer’s order. AI Engine, the most widely installed WordPress AI plugin with 90,000+ active installations on its listing as read on 14 October 2026, offers function calling in its Pro version for exactly this kind of lookup. I am building a WordPress chatbot called DFYe, which is not on sale, so this is the mechanism and its traps rather than a product page.
Why order status is the first integration most shops want
“Where is my order?” is the question online shops answer most often, and the answer already exists in the shop’s database. That makes it the classic first job for a chatbot that does more than read pages: the information is structured, the question is repetitive, and the answer rarely needs a person.
It is also the first integration that touches private data. Answering from public pages, as described in how a RAG chatbot works, exposes nothing that is not already published. Looking up an order exposes a name, an address, a purchase and sometimes a phone number. Everything below follows from that difference.
What are the ways to connect a chatbot to WooCommerce orders?
| Option | Best for | Why it works | Main limit |
|---|---|---|---|
| WordPress plugin with function calling (AI Engine Pro, custom code) | Shops that want everything inside WordPress | Uses the logged-in session and WooCommerce data directly | Needs careful identity checks and some configuration |
| Hosted chatbot with an order lookup action | Shops already using a hosted platform | Set up through the vendor’s integration | Order data leaves your site for the vendor; check the processor chain |
| Helpdesk with WooCommerce integration | Shops with a support team | Agents and the AI share the same order view | A larger product than the problem may need |
| My Account page plus good emails, no bot | Shops with few order questions | No new risk, no new cost | Customers must log in or find the email |
Two of those options need more than a cell. The hosted route, used by platforms such as Chatbase, which lists order lookup among its agent actions on its homepage, means the order details pass through the vendor, which belongs in your records of processing as our post on whether AI chatbots are GDPR compliant explains. And the last row is a serious option, not a placeholder: many shops discover that a clear shipping email removes most of the questions a bot would answer.
How should the bot verify who is asking?
Never by trusting what is typed into the chat. A visitor claiming “I am Jane, my order is 1042” proves nothing, and a bot that answers anyway lets anyone walk through order numbers one by one and read other people’s details. Order numbers in WooCommerce are usually sequential, which makes guessing trivial.
Three verification patterns are sensible:
- Logged-in customer. If the visitor is signed in to their account, the site already knows who they are. The bot can list that customer’s recent orders and nothing else. This is the strongest option.
- Order number plus billing email. For guests, require both, compare them on the server, and only return the order when they match. Limit attempts per visitor to stop guessing.
- One-time link by email. For anything beyond status, such as changing an address, send a link to the order’s email address and let the customer continue there.
Whatever the pattern, the check happens in your site’s code, never in the model’s judgment. The model can ask for the order number and email; your code decides whether they match.
What should the bot return?
Less than you might expect. The customer asking “where is my order?” needs the status in plain words, the date it was placed, what happens next, and a tracking link if one exists. They do not need their full address read back to them in a chat window, and the bot does not need the payment details at all.
Translate statuses rather than repeating them. WooCommerce’s order status documentation defines them, and each one deserves a sentence a customer understands:
| WooCommerce status | What it means | What the bot should tell the customer |
|---|---|---|
| Pending payment | Order received, no payment made | Payment has not come through; here is how to complete it |
| On hold | Awaiting payment confirmation, common with bank transfers | We are waiting for your payment to clear; this can take a few days |
| Processing | Paid, stock reduced, awaiting fulfilment | Paid and being prepared for shipping |
| Completed | Fulfilled | Your order has been shipped or delivered; here is the tracking link if we have one |
| Cancelled | Cancelled by the shop or customer | This order was cancelled; contact us if that is unexpected |
| Refunded | Refunded in full | This order was refunded; refunds can take a few days to appear |
| Failed | Payment failed or was declined | The payment did not go through; you can try again |
Stores often add custom statuses through plugins, such as “shipped” or “ready for pickup”. List yours and give each a sentence too, or the bot will improvise.
What about tracking numbers?
WooCommerce does not store carrier tracking numbers by default. They come from an extension such as WooCommerce’s own Shipment Tracking, from your shipping or label plugin, or from your fulfilment service, and they are saved as data on the order.
If that data exists, the same verified lookup can return the carrier and the tracking link. If it does not, the bot should not guess or invent one. The honest answer is the status plus a pointer to the shipping confirmation email, which is where the tracking number usually lives.
How do you keep the integration safe?
Order lookup is a tool the model can call, which puts it squarely in the territory the OWASP Top 10 for LLM Applications calls excessive agency. Keep the tool small:
- Read-only. The lookup tool reads orders. Cancelling, refunding and changing addresses go to a person or to the customer’s account page.
- Scoped keys. If you use REST API keys, create them with read permission only, store them server side, and never place them where the browser can see them.
- Server-side identity checks, as above, with attempt limits.
- Minimal fields. Return status, date, items summary and tracking; leave out addresses and payment data unless the customer is logged in and genuinely needs them.
- Logged and reviewed. Keep lookup logs for a short, defined period and read a sample, so you notice odd patterns such as one visitor trying many order numbers.
Our broader guide on whether an AI website chatbot is secure covers the risks that apply to every tool a bot can call.
What does setting it up look like?
On WordPress with a plugin that supports function calling, the shape is the same whatever the plugin:
- Define a function such as “get order status” that takes an order number and an email, or uses the logged-in customer.
- In that function’s code, verify identity, load the order through WooCommerce, and return only the approved fields.
- Describe the function to the model in plain words, including when to use it and when to ask for the email first.
- Write the status translations and the refusal rule: if verification fails, say so and offer the account page or a contact route.
- Test with your own orders, a guest order, a wrong email, a cancelled order and a guessed order number.
When is an order status chatbot the wrong answer?
When the shop’s own emails already do the job. A clear order confirmation, a shipping email with a tracking link and a My Account page that shows status answer most “where is my order?” questions with no new risk and no running cost. Fix those first; they also reduce the questions a bot would get.
When order questions are rare. A shop that receives a handful a week gains little from an integration that needs building, testing and reviewing.
And when you cannot verify identity properly, for example because most orders are guest checkouts with no reliable email. A bot that cannot verify should not look up anything, and a contact form handled by a person is the safer design.
If “where is my order?” is a large share of your inbox, the integration earns its keep, provided it is read-only, verified on the server and reviewed.
Key takeaways
A chatbot can check WooCommerce order status through the REST API or a plugin calling WooCommerce directly, and AI Engine Pro supports the function calling this needs on WordPress. The deciding factor is identity: verify a logged-in session or an order number matched with the billing email on the server, limit attempts and return only that order. Keep the tool read-only, translate statuses into plain sentences, return tracking only when the order actually stores it, and log lookups for review. Good order emails and a clear account page solve much of the problem before any bot is built.
What owners ask us most
Can a chatbot check WooCommerce order status?
Yes, through the WooCommerce REST API or a plugin that calls WooCommerce functions directly. The safe version verifies who is asking before it looks anything up: a logged-in customer, or an order number together with the billing email, and it returns only that order. AI Engine Pro offers function calling for this kind of lookup on WordPress, and hosted tools such as Chatbase list order lookup among their actions.
Is it safe to let a chatbot look up orders?
Only if identity is checked by your site, not claimed in the chat. A bot that answers for any order number it is given lets anyone enumerate orders and read names, addresses and purchases. Require the customer to be logged in, or match the order number with the billing email, limit attempts, return only the fields the customer needs, and make the lookup read-only.
What do WooCommerce order statuses mean to a customer?
Pending payment means the order exists but nothing has been paid. On hold means payment is awaiting confirmation, common with bank transfers. Processing means it is paid and waiting to ship. Completed means it has been fulfilled. Cancelled, refunded and failed are what they sound like. A good bot translates these into plain sentences and says what happens next, rather than repeating the label.
Can the chatbot show tracking numbers too?
Only if the tracking data is stored on the order. WooCommerce itself does not hold carrier tracking by default; an extension such as Shipment Tracking or your shipping plugin adds it as order data. Once it is there, the same verified lookup can return the carrier and tracking link. Without it, the honest answer is the order status plus a pointer to the shipping email.
When is an order status chatbot not worth building?
When your order emails and account page already answer the question well and few customers ask. A clear order confirmation, a shipping email with tracking, and a My Account page that shows status cover most of it at no risk. Build the bot when where is my order is a large share of your support inbox, not because the feature exists.
