Shopify and WooCommerce order lookups

Store installation and order access are separate#

Use Business or Scale and sign in as an owner or admin. A connected website and an installed widget are prerequisites for the customer experience, but neither automatically grants access to a store’s private orders.

The native Shopify adapter requires a separately installed and authorized Reesponder Shopify app. The current theme-snippet installation works without that app; it does not connect order data. If the store uses only the snippet, use an authorized custom HTTP endpoint supplied by your store integration or developer. Do not paste a Shopify merchant app secret into the Action form.

Check which integration actually owns private order access before choosing a starter. A detected launcher proves the storefront script is present; it says nothing about an order credential or protected customer-email permission.

Authorize Shopify order access when available#

For an existing app-connected store, open the Reesponder app in Shopify, choose the order-lookup connection and approve the requested read_orders access. Reesponder checks that customer email can actually be queried. The store’s myshopify.com origin is used for the native Action, not its public custom storefront domain.

The app needs protected customer-email access in addition to broad order permission. Shopify’s default order access covers the last 60 days; access to older orders requires additional approved permissions. See Shopify’s access-scope documentation. Distribution, store eligibility and provider approval are separate from enabling a Reesponder draft.

Save the native order Action, test a recent existing order and its actual email, review the returned payment and fulfillment states, then enable it. Expired store authorization may require reconnection; disconnecting the store removes its saved order credentials.

The lookup uses the order name and an exact match after an optional leading # is removed. Copy the real reference from a controlled order rather than assuming a numeric database ID has the same meaning.

Connect a read-only WooCommerce key#

In the store’s WordPress admin, open WooCommerce → Settings → Advanced → REST API, create a key for a user allowed to read orders and select Read permission. See WooCommerce’s API key guide. Copy the generated consumer key and secret securely.

In Actions, start WooCommerce order status, enter the public HTTPS store origin and save the credential as consumer_key:consumer_secret. The adapter uses HTTP Basic authentication over HTTPS to the store’s /wp-json/wc/v3/orders/ endpoint. It does not send your credential to the visitor.

The input must be WooCommerce’s numeric order ID. A custom order-number plugin’s displayed reference may differ from that ID. Confirm it with the store before testing. A redirecting origin, unavailable REST endpoint or stripped Authorization header can cause a connection failure.

For a WordPress installation in a subdirectory, use its correct final HTTPS store base rather than an origin that redirects elsewhere. Verify the REST route your store actually exposes before configuring the read credential.

Exactly what the customer receives#

Before returning these fields, the adapter compares the order email with the verified conversation email, ignoring letter case. A missing or different email yields order_not_found. Addresses, internal notes and a raw provider response are not exposed.

Payment and fulfillment are distinct Shopify states. A paid order is not necessarily shipped. Present the native fields with their actual meanings instead of collapsing them into an overbroad promise that everything is complete.

Test both ownership paths#

Test an existing order with the matching email and an order with a nonmatching email. Only the first should return a summary. Then verify the actual widget flow and code email from the installed storefront. A portal test uses an admin-supplied test email; it does not replace customer verification.

If a lookup fails, check the exact reference, stored order email, provider permission and credential. Shopify may require reconnecting or permission approval. WooCommerce may require a replacement read-only key. Save and run a fresh test after any configuration change.

A fresh test after changing credentials demonstrates the current connection, not all possible historical orders. Use a recent known order first, then test any additional range your authorized store setup is intended to support.

Worked example: a custom WooCommerce order number#

Your store displays reference WEB-2026-1042 on customer receipts, but its WooCommerce order has numeric ID 1042. The native adapter accepts the numeric ID, optionally with a leading #. It does not understand every custom order-number plugin's display format. Testing the visible alphanumeric reference can therefore fail even when the read credential and email are correct.

Confirm the actual numeric ID in authorized store tools, then test that order with its recorded billing email. Test it again with a different controlled email and verify no private summary is returned. This separates reference format, service access and ownership into three useful checks.

If customers normally know only the custom display reference, provide an authorized custom adapter that resolves it under your ownership rules, or use a clear supported collection instruction. Do not tell visitors to search for internal IDs they cannot see, and do not weaken verification to compensate for a reference mismatch.

Finally, complete the public widget flow using the supported reference and your own email. Compare status, total and currency with the real order, then inspect the matching activity. The WordPress widget plugin itself has not granted this separate WooCommerce REST access.

Verify access, format and ownership separately#

Use a known matching order, the same order with a wrong email, an absent reference and a deliberately unavailable connection. Check the native summary against the real provider record. Keep private notes and addresses outside screenshots and diagnostic messages.

If the valid fixture fails, inspect the input format, provider permissions, credential and stored order email in that order. Save and test after configuration changes. Avoid treating a normal ownership-protecting not-found result as a reason to switch off verification.

Choose the identifier that the adapter accepts#

The Shopify native input is order_number. After removing one leading #, it accepts letters, digits, underscores or hyphens, up to sixty-four characters. The adapter searches by order name and selects an exact matching name whose email matches the verified conversation identity. Use the real name from a controlled store order.

The WooCommerce input is also order_number, but its native lookup uses a numeric order ID of one to twenty digits after the optional leading #. A custom display reference is not automatically converted. Document the supported reference in your customer-facing label and your test fixtures.

The email must be the address recorded on the order. Native matching ignores letter case, but it does not grant access to orders belonging to a different mailbox or infer ownership from a customer name. A missing order email cannot supply the required ownership comparison.

If your business uses organization accounts, alternative references or additional authorization rules, use a narrow custom integration that explicitly implements them. The native adapter's fixed summary is useful when its contract fits; it is not a general store administration API.

Troubleshoot a private order connection in layers#

First confirm the provider connection exists for the intended website and that the workspace has active Business or Scale access. The native Shopify credential is tied to its separately connected store; an unrelated app credential or theme snippet cannot substitute. WooCommerce requires its own read credential even when the widget plugin is connected.

Then check the actual reference and email on a known order. For Shopify, distinguish permission or reconnection errors from an order_not_found result. Protected customer-email access matters because the adapter cannot authorize an order whose email it cannot query. For WooCommerce, inspect whether its REST route accepts the configured Basic authorization without redirects or header stripping.

Next compare the returned summary with the owning system. A total without the expected currency or a misunderstood fulfillment code deserves review even when the request succeeded. Native results deliberately omit addresses, notes and arbitrary provider fields.

Finally, reproduce the customer verification flow from the storefront using your own mailbox. Capture safe error category, website, time and run reference for support. Do not paste provider keys or another customer's order body. A connection that passes an administrator test can still depend on live email delivery and the visitor supplying the correct record identity.