Answer order and stock questions from your WooCommerce shop

The goal: stop answers being written around the facts. “Where’s my order?”, “is this in stock?”, “was I actually charged?”, “why won’t my discount code work?” — none of those are writing problems. The answer exists in your shop, and someone is being paid to go and look it up. Connect the shop and a flow does the looking, so the reply is grounded in the real order rather than in a plausible guess.

This is the other half of a support desk: Answer Zendesk tickets brings the question in, these steps find the answer.

Read-only, by design

Nothing here can change your shop. There is no create-order step, no refund step, no stock adjustment — the connector exposes no write path at all. A wrong answer about an order is a bug you can fix; a wrong write is an incident.

Step 1 — Connect your shop

Go to Settings → Connections → Apps and open the E-commerce section, then pick WooCommerce.

In WordPress, go to WooCommerce → Settings → Advanced → REST API and generate a key pair with Read permission. Then paste into Routario:

• Store URL — your shop’s home page, e.g. https://www.yourshop.com.
• Consumer key — starts ck_.
• Consumer secret — starts cs_.

Click Connect. Routario reads a single product back as a check — a product rather than an order, so testing the connection doesn’t pull customer data. Your key and secret are stored encrypted and never shown again.

Paste whatever you’ve got for the store URL

If you copied the full API address out of your browser — https://www.yourshop.com/wp-json/wc/v3/orders?per_page=100 — paste it anyway. Routario trims it back to the shop address. A bare www.yourshop.com works too.

Two things that will be refused, both on purpose:

• A plain http:// shop. The key and secret travel on every request, and over plain http they travel in the clear.
• Credentials in the address. WooCommerce also accepts the key and secret as ?consumer_key=…&consumer_secret=…, which is what most tutorials show. Routario won’t do it: secrets in a URL end up in access logs, proxy logs and browser history.

If Connect fails, the message tells you which of the two usual causes it was: a 403 almost always means the key was created with the wrong permission (Write-only instead of Read), and a 404 means the address isn’t a WooCommerce shop.

Step 1b — Say what “Out of stock” means in your shop

On the same page there is one more question, and it is worth thirty seconds: What “Out of stock” means in this shop.

WooCommerce gives you three stock states — In stock, Out of stock, On backorder — and attaches no commercial meaning to any of them. Shops use them differently, and the difference is invisible in the data. Many shops run this convention:

• On backorder — we still sell it, there just isn’t one on the shelf today.
• Out of stock — we have stopped selling this. It is finished.

If that is how your shop works, choose The product is discontinued. Every lookup then reports an extra field, availability, alongside the raw stock state:

Your stock state	availability
In stock	available
On backorder	temporarily_unavailable
Out of stock	discontinued

If your shop means Out of stock literally, choose Just out of stock right now instead, and nothing is ever reported as discontinued.

The default assumes nothing, and that is the point

Out of the box the setting is Don’t assume anything, and availability comes back as unknown on every product.

That is deliberate. Silence is not “yes, we still sell it”. A shop that has not declared its convention gives no basis for either answer, and a reply that reads an empty shelf as “discontinued” — or a discontinued product as “available” — is wrong in a way the customer acts on. Until you answer this question, a flow should treat unknown as ask a person, not as a yes.

Keep the shop honest, or the field lies

This setting only reads what your shop already says. If a product is finished but still marked In stock, every lookup will keep offering it — correctly, because that is what the shop states.

So the setting is a commitment as much as a preference: once you pick “discontinued”, marking a retired product Out of stock in WooCommerce is what retires it everywhere — the website filter, the catalogue, and every drafted reply, in one edit.

Step 2 — Look one thing up

Find WooCommerce order

The workhorse. Give it an order number or a customer e-mail:

• With an order number, it fetches that order.
• With an e-mail, it returns their most recent order, and lists any older ones in other_orders so a reply can ask which one they mean.
• Give it both and the order number wins, because it’s unambiguous.

Both keys exist because a support ticket carries an order number only when the customer bothered to paste one, which on most forms is optional. E-mail is the fallback that fires most often.

You get back the status, whether it’s paid, when it was placed and completed, the total and currency, the destination country, and line_items — what they actually bought, each with a name, SKU and quantity.

Two more outputs tell a live order from history, which matters because the “most recent” order for an e-mail can be years old:

• age_days — whole days since it was placed (-1 when there’s no order).
• is_open — true while the status is one the shop still works on: processing or on-hold. If your shop adds statuses of its own (say, an order waiting for a spare part), list them in Open statuses so an old order that is still being worked on isn’t treated as history.

A rule like “only mention an order older than 45 days when it is still open” is then a condition on those two, not a code step.

It’s line_items, not items

Writing {{ find_order.items }} in a template will not give you the products — it resolves to something else entirely and quietly renders nothing. The output is named line_items specifically to avoid that trap.

Branch on found. A customer quoting an order number that doesn’t exist, or writing in from a different address than they ordered with, is completely normal — and it needs a question, not an invented answer.

Check WooCommerce stock

Looks one product up by SKU and says whether it can actually be bought right now. It returns the name, the price, how many are left, and the link to the product page — which is what an “order it here” line should point at.

The important part is that it keeps three different negatives apart:

• found is false — the shop has no such SKU. The part number is wrong, or it isn’t something you sell.
• found is true but in_stock is false — the right part exists, and there are none left today.
• availability is discontinued — the right part exists and you have stopped selling it. It is not coming back.

Those are three different replies. “Wrong part number” sends them to check their invoice; “none left” invites them to wait or be told when it lands; “we no longer make it” should offer the nearest thing you do sell. Answering the third with the second is how a customer ends up waiting for a restock that will never happen.

availability is only meaningful once you have answered Step 1b; before that it is unknown and says nothing.

Gate any “you can order this” line on this step rather than on what the drafting model believes.

List WooCommerce orders

When the question is about a group rather than one order. Filters combine:

• status — pending, processing, on-hold, completed, cancelled, refunded, failed.
• after / before — when orders were placed.
• modified_after / modified_before — when they were last changed.
• search — matches customer name or e-mail.
• product_id — everyone who bought a particular thing, e.g. when a batch turns out faulty.

Placed and changed are different questions

A scheduled flow watching for things that moved wants modified_after, not after. An order placed last month that only just shipped is invisible to a filter on when it was placed. Overlap your polling window by a minute or two: the boundary is exclusive, so an order changed at exactly the timestamp you pass is not returned.

List WooCommerce products

The catalogue search — for when a customer describes a part instead of naming its code. Filters on free text, an exact sku, a category, and stock state (instock, outofstock, onbackorder). Each result carries the categories the product sits in, and its availability — so a list of suggestions can drop the ones you no longer sell before a customer ever sees them.

Each result also carries an excerpt of the product’s own description, cleaned of the shop’s page-builder markup (default 600 characters, tunable per step). Anything clipped ends with a note saying so and sets description_truncated.

Reach for Check WooCommerce stock instead when you already have the SKU: it’s the direct answer, it distinguishes an unknown code from an empty shelf, and — being a single-product lookup — it carries the whole description rather than an excerpt.

List WooCommerce categories

Your shop’s own category vocabulary — id, name, slug, parent, and how many products sit in each. Two jobs:

• It is the only place the numeric category id appears. Nothing in the product API shows it, so without this the category filter is usable only by someone who has opened the shop admin. (category on List WooCommerce products also accepts a name or slug and resolves it for you.)
• It answers “what do you carry for X?” — a question a product-name search cannot.

Never say what is not included without reading the description

The product’s description is the only place “what’s in the box” lives. It is not in the name, not in the attributes, and not in the categories.

A customer was told that tire levers and an Emergency Side Stand are not included with a CFMOTO 800MT-X skidplate. The shop’s own description lists both, by name. Nothing had fetched it, so the model had no source and guessed — and guessed a negative, which is the one kind of guess a customer acts on.

Two rules follow:

• For a question about what a specific product is or contains, use Check WooCommerce stock — it carries the full description. The plural search carries an excerpt sized for scanning, not for enumerating.
• A truncated description is not evidence of absence. When description_truncated is true you have read part of the text; not finding something in it says nothing about the product. Branch on that flag rather than on whether a word appears.

A name search is not a fitment check

search matches the product title and nothing else. A shop files a part under the machine it fits, and that fact is in the category, not the title — so a search for a model name misses every brand-wide product.

This is not hypothetical. A customer asked whether a shop sold suspension for a CFMOTO 450MT; a search for “CFMOTO 450MT” returned nine products, none of them suspension, and the reply said we don’t sell it. The product is called “TRACTIVE SUSPENSION for CFMOTO” — brand-wide, and unable to match a model-name search by construction.

An empty result from search proves nothing about what you stock. Check the categories, or read the workspace catalogue’s recorded fitment, before a reply says “we don’t have that”. See Record what a product fits.

Neither list step pages

Both return at most the number you ask for and stop. has_more tells you the cap was hit. That’s deliberate — a support answer never needs order 101, and silently walking every page turns one question into an unbounded crawl of a live shop.

Tracking: only if your shop publishes it

Find WooCommerce order and List WooCommerce orders both return a carrier and a tracking_number — but only when your shop puts them on the order. Whether yours does is the whole question, and it is worth understanding why, because “where is my parcel?” is one of the most common things a shop gets asked.

WooCommerce itself has no concept of tracking. It arrives on an order as extra data written by whichever shipment-tracking plugin you run, and every plugin stores it differently — which is why Routario can’t read it out of a standard shop. What it can read is two plain fields, carrier and tracking_number, if your shop is set up to expose them. Some shops publish them directly; others have a developer add a few lines that copy the plugin’s data onto the order. Ask whoever looks after your WordPress whether those two fields are on your orders API.

When they’re filled, answer from them: carrier reads like dpd or fedex, and tracking_number is the number the carrier knows. An order that shipped as several parcels can carry several numbers separated by commas — pass the whole value through rather than taking the first.

When they’re empty, they’re empty for one of two reasons and neither means “delivered”: the parcel has no label yet, or your shop doesn’t publish these fields at all. Either way you don’t know, so route the question to a person.

When was the label made? On the day a label appears, the parcel is usually still with you — the courier hasn’t collected it, and the address can often still be changed. tracking_added_today is true on that day, and tracking_added_at gives the time:

• If your tracking plugin records when it shipped (date_shipped on its tracking items), that time is used (tracking_added_source: shop).
• If it doesn’t, Routario uses the first time it saw the tracking number (tracking_added_source: observed) — but only when it knows the number wasn’t there before: it looked the order up earlier without one, or the order was placed since the previous working day. An old order that was already labelled the first time anyone asked about it gets an empty tracking_added_at, never a guess.

completed is not “it arrived”

The tempting shortcut is to answer a tracking question from status: completed. Completed means the shop finished with the order, not that anything was scanned or delivered. Presented as an answer to “where is my parcel”, it’s a confident wrong reply — which is worse than no reply, because nobody checks it.

Branch on carrier being non-empty, not on the order status.

Answer “why isn’t my discount code working?”

A customer types a code, it doesn’t apply, and they write in. The answer is almost always in the shop, and it’s almost never “our website is broken”.

Check WooCommerce coupon

Give it a code and it tells you whether that code works right now. It comes back with the type and amount of the discount, when it expires, how many times it’s been used and any usage limit, the minimum order it needs, and whether it includes free shipping.

The useful part is the three plain answers it works out for you, so a reply doesn’t have to reason about it:

• expired — the expiry date has passed.
• exhausted — the code has a usage limit and has hit it. A one-time code is just a limit of one.
• email_restricted — the code only works for particular e-mail addresses. The shop deliberately does not say which, so nobody can check this from a reply. Hand it to a colleague.

usable folds all three together and is the field to branch on. It answers “is this code live right now” — not “will it work on this customer’s basket”. The minimum order, product scope and free-shipping flag come back alongside precisely because those are yours to weigh.

A code that doesn’t exist is not an expired code

found is false when the shop has never heard of the code — almost always a typo. That’s a different reply from a real code that ran out. Telling someone their code expired when they actually mistyped it sends them off looking for a new code instead of retyping the one they have.

List WooCommerce coupons

Every coupon in the shop, newest first — for a report, a morning check of what expired overnight, or a table you keep current. Unlike the order and product lists, this one does page through until it has them all, because the question it serves is a sweep: a half-read list would quietly imply that the codes it didn’t reach no longer exist.

Each coupon in coupons has the same shape Check WooCommerce coupon returns, including expired, exhausted, email_restricted and usable.

Keep a discount table that’s never out of date

Point this at a scheduled flow — List WooCommerce coupons into Sync to Table with the key column set to code — and your team gets a live list of codes they can look at, refreshed as often as you like. Because it matches on the code, re-running updates the same rows instead of piling up duplicates, so the table converges rather than growing.

If your team also keeps their own notes against a code — who it’s for, whether it’s approved to hand out — put those in their own columns. The sync only fills the columns it knows about and leaves the rest alone, so the notes survive every refresh.

A worked example: the order question

A support flow handling “where’s my order?” reads:

1. Find WooCommerce order with the order number from the ticket, falling back to the requester’s e-mail.
2. On the missing path, draft a reply asking for the order number from their confirmation e-mail — don’t guess.
3. On the found path, Ask AI drafts the answer, given the status, the payment state and line_items.
4. Post the draft back for a human to approve.

Because step 3 is handed real values, the draft says “your order of 2× Windshield Kit, placed on 4 August, was paid and completed on the 6th” rather than something that merely reads like an answer.

Testing it on your own shop

Every step above can be exercised by hand before you wire it into anything. The repository ships ops/woocommerce-smoke-flows.py, which creates four tiny flows — one per step — each shaped ask a question → run the step → show the result. Run one, type a known order number or SKU, and read the pop-up.

They’re worth keeping and re-running after an upgrade: the pop-ups name every output explicitly, so anything that stops working shows up as a blank rather than passing quietly.

Where to go next

• Answer Zendesk tickets with a drafted reply — the support desk these lookups feed.
• Branch on an AI decision — routing a question to the right lookup in the first place.
• Template variables — how to reference a step’s output, like {{ find_order.line_items }}, further down the flow.