Can an AI support agent look up a real Shopify order?

Yes, if it is connected to the store with a credential of its own. Glassdesk reads the order through Shopify's read-only Admin API using the token the merchant granted during install, and returns the order's payment status, fulfillment status, line items and tracking number. It never writes to the store.

How does the AI find which order the customer means?

It matches an order number written in the ticket, in the form #1234. If the customer does not give one, it falls back to the address the ticket was sent from and takes that customer's most recent order. Only the sender address your helpdesk recorded is used — an email address typed into the message body is ignored, so nobody can read a stranger's order by naming their address. If neither matches, no lookup happens and the ticket is answered from the help centre alone or escalated.

Can the AI make up a delivery date?

It should not be able to. The order record is injected into the same retrieval pipeline as help-centre content, so the reply has to cite it like any other source, and a citation that was not retrieved is stripped. If nothing survives that check the ticket escalates to a human instead of being sent.

What happens if the Shopify connection breaks?

The agent keeps answering, without order data, rather than dead-ending the customer. Separately, a genuine 401 — meaning the token was revoked — clears the stored connection, alerts us, and emails the merchant to reconnect. Rate limits, scope errors and Shopify outages are treated as transient and never clear a working connection.

How an AI agent answers "where's my order?" without inventing a delivery date

The failure mode this exists to prevent

An AI agent with no order data still answers order questions. It has read your shipping policy, so it produces something fluent: "Standard delivery usually takes 3–5 business days, so your order should arrive shortly!"

That sentence is generated from a policy page, not from the order. The order might be unfulfilled, refunded, or stuck. The customer now has a delivery date from your brand that nothing in your business is committed to, and the ticket you avoided arrives next week, angrier.

The fix is not a better prompt. It is refusing to answer the question without the record.

What actually happens on a WISMO ticket

The order is identified from the ticket. Glassdesk looks for a #1234-style number in the subject or body. If there is none, it falls back to the address the ticket was sent from and takes that customer's most recent order. Neither matches, no lookup.
Your store is queried, read-only. A single call to Shopify's Admin API, using your credential, for that one order.
The order becomes a source document. The record is turned into a passage — payment status, fulfillment status, items, tracking — and dropped into retrieval alongside your help-centre content.
The reply has to cite it. This is the important step. Live order data is not handed to the model as trusted background; it competes as a citable source like everything else, and any citation the agent did not actually retrieve is stripped out.
Nothing left to cite means escalation. If the order data does not survive that check, the ticket goes to a human with context rather than out to the customer.

Why route order data through the citation check at all? Because the alternative is a second, unverified channel into the answer. If live data bypassed the check, every guarantee we make about citations would carry a silent exception for the highest-stakes ticket type on the site. One path in, one set of rules.

What it can see

Field	What the customer gets
Payment status	Paid, pending, refunded, partially refunded
Fulfillment status	Fulfilled or unfulfilled — the difference between "it's coming" and "it hasn't shipped"
Line items	What was actually ordered, and how many
Tracking	Tracking number, carrier and link when one exists — and explicitly "none on file" when it doesn't
Order date	When it was placed

Note the fourth row. "No tracking number yet" is recorded as a fact rather than left blank, because a blank field is exactly what a language model fills in helpfully.

What it deliberately cannot do

Four limits worth knowing before you buy, not after.

It cannot match an email the customer merely types. The email it matches on is the address the ticket was sent from — the one your helpdesk recorded, which the sender proved they control by receiving mail at it. An address written into the message body is ignored, deliberately: honouring it would let anyone email your support desk, name a stranger's address, and be shown that stranger's items and tracking.
It cannot change anything. The connection is read-only. Refunds, address edits and cancellations are not something we do quietly on your behalf; they are a separate approval flow, still marked coming soon on our own site.
It cannot tell you where the parcel physically is. It reports what Shopify knows. If the carrier has not scanned it, neither we nor your team can see more.
It cannot see another merchant's store. Each connection uses that merchant's own token, granted by that merchant. There is no shared platform credential — a merchant who has not connected Shopify simply gets no order lookup, exactly like one who never signed up.

When the lookup fails

Connections break. Staff remove apps, plans lapse, Shopify has an incident. What matters is what the system does next.

What went wrong	What the customer sees	What we do
Rate limit	Nothing — it retries with backoff	Nothing. Transient.
Shopify outage or error	An answer without order data, or an escalation	Logged. The connection is not touched.
Token revoked	An answer without order data, or an escalation	Connection cleared, we're alerted, and you get an email asking you to reconnect

That last row is the one that took real work. A revoked token is the only disconnection you did not choose — nobody clicked anything — so it is the only one where silence is dangerous. Without an alert, the agent would carry on answering order questions slightly worse, forever, and the first person to notice would be a customer.

The other two rows matter just as much in the opposite direction. Treating a Shopify outage as a revocation would disconnect every merchant at once during an incident, and each of them would have to reconnect by hand. Only a genuine authentication failure counts.

Honest status: this is a capability, not yet a track record. The lookup is live, and a real store has completed the connection end to end. But no merchant has yet run a live "where's my order?" ticket through it in production. We hold "order status" back from our marketplace listing's headline ticket types for exactly that reason, and it goes back in when a merchant has resolved them end to end — not before. We would rather publish the gap than a benchmark nobody can check.

What to ask any vendor about order lookups

"Whose credential does it use?" If the answer is a platform-level integration rather than a token you granted and can revoke, you cannot end the access on your own.
"Can it write to my store?" Read-only is a choice. Ask what the app requests, not what it promises to do.
"What does it say when the lookup fails?" The honest answer is "an answer without order data, or a handoff." The worrying answer is a confident delivery estimate.
"How does it match the order?" Vague answers here usually mean fuzzy matching, and fuzzy matching on orders means occasionally telling a customer about somebody else's parcel.

Connect your store in a minute, in shadow mode

Install into Gorgias, connect Shopify with your own credential, and watch it draft WISMO replies without sending any of them. You will see the order data it read, the passage it cited, and the confidence it assigned — before a single customer does.

Start my flat-rate trial →