Corthex · WooCommerce / Customer identity
Whose order is the chatbot allowed to see?
An order-status answer starts with the customer’s identity, then the store connection. Knowing an order number is not the same as being allowed to read it.
Permission diagram · Fictional example
With the connector and tools enabled, use the verified customer context to request their order. The actual store response determines what can be answered.
A customer account is a boundary, not just a greeting.
A shopper asking where their order is gives you two different tasks. First, establish which customer the storefront has actually authenticated. Then request the information that belongs to that customer. The chat message itself cannot establish ownership: someone can type a familiar email address or copy a number from a receipt. Treat those details as search context only after the store has supplied the required verified identity.
Corthex’s native WooCommerce own-order tools use the verified signed-in store customer. This identity is distinct from a Corthex administrator account, an optional contact form and the visitor’s conversation history. Installing the widget on a page does not turn any of those into a customer session. Test the customer account on the storefront where the widget runs, rather than relying on an administrator’s dashboard preview.
Four conditions must meet in the same shop.
Install and activate the Corthex AI plugin with WooCommerce active. Use Connect to Corthex in WordPress, choose the intended assistant and confirm the pairing. Enable the relevant commerce tools for that assistant. Finally, open the store as a signed-in customer whose account owns the test order. A working generic chat response proves the assistant can answer, but says nothing by itself about this four-part chain.
The plugin pairs with a scoped connector token; you do not need to create a WooCommerce REST API key manually for this route. Full customer-profile sharing is a separate opt-in and is off by default. Do not switch it on merely to make a guest lookup work: it does not replace verified customer identity. If you use only the generic JavaScript embed, first assess whether the native connector or a deliberately designed custom integration is needed.
Keep the assistant-to-store association explicit when testing multiple shops or environments. A staging storefront paired to one assistant and a production conversation opened under another is not a useful access test. Record the environment, assistant name, plugin version and customer role in your test notes. Use fictional orders and your own test accounts; customer transcripts and real delivery addresses are unnecessary evidence.
An order state is not a carrier promise.
Separate three questions: has the store accepted the order, what state does its record currently have, and when will the parcel arrive? WooCommerce’s order statuses describe its order workflow. Processing and Completed have meanings in that workflow; they do not by themselves provide a live carrier scan or a delivery appointment. Extra shipping extensions can add information, but its availability must be verified in your own connected setup.
A useful answer states what the store actually returned and explains what remains unknown. For example: the fictional test order is Processing; the available result contains no delivery date, so the assistant cannot confirm arrival tomorrow. A delivery-policy source can explain usual lead times, but must not be presented as the private order’s actual shipment state. When the requested fact is unavailable, offer the store’s support route without pretending a lookup succeeded.
Repeatable permission checks
Test the refusal as carefully as the answer.
Own account, own order
Sign in with test customer A. Ask for their test order’s current state. Compare the answer with the store record and the tool result, not an assumed delivery date.
Pass: only the permitted customer’s order context is used. Missing fields are acknowledged. Capture a redacted screenshot and the expected state.
Guest who knows the number
Sign out or use a private browser window. Supply the same email and order number in chat. These details must not become a substitute for the required login.
Pass: no private order details are revealed. The visitor gets a practical sign-in or support route, without confirmation that someone else’s order exists.
Another signed-in customer
Sign in as test customer B and request A’s order. This distinguishes ownership from the much weaker condition of being signed in as anyone.
Pass: the lookup does not cross the customer boundary. Re-run after sign-out/account switching and after changes to connection or session handling.
Decide what happens when access is unavailable.
A safe refusal should still help the customer continue. Tell them which store account to use, link to the shop’s normal account area where appropriate, or explain how support can verify the request through its established process. Never ask for passwords or copy a private API credential into the chat. Avoid disclosing whether an unrelated order exists while explaining the boundary.
If staff handoff is configured on Pro or higher, test it separately with staff online and offline. A request waiting for a teammate is different from an immediate live reply. Write down the promised next step and check that your team can actually follow it. For failures earlier in the chain, use the diagnostic guide instead of broadening customer-data permissions.