Your listings go out and no orders come back. «Connected» was never one thing.

Publishing listings and reading orders are separate permissions on Shopify and on BigCommerce. You can hold one without the other with the app properly installed — and what comes back when you do changes completely depending on which platform you are on.

The store is connected. The listings went up, they are live, you can see them. Then a sale happens and nothing lands in your software. You reconnect. Same green light, same silence.

«Connected» is not one thing. Publishing listings and reading orders are separate permissions, and you can hold one without the other with the app properly installed. And it is not that no error arrives — it is that the error does not always arrive where you are looking: on one platform it hides inside a response marked 200 OK, on another it is a plain 403.

Two permissions, and they are not next to each other

Shopify lists them as separate rows of the same table. read_products and write_products cover «Product, ProductVariant, Collection, ResourceFeedback, SellingPlan». read_orders and write_orders cover «AbandonedCheckout, Fulfillment, Order, OrderTransaction, DeliveryCarrierService». Nothing in the first list ever hands you the second.

BigCommerce splits the same way, with a read-only twin for each: store_v2_orders is «View and modify orders», store_v2_orders_read_only is «View orders», and the two product scopes sit beside them. Those read-only twins exist so «you can limit some accounts to sending GET and HEAD requests», and what BigCommerce recommends is the principle behind them: give each account only the privileges its task actually needs.

Installed is not the same as authorised

Shopify says it outright about optional scopes: «The granted scopes for your app installation don't change until your app requests the new scopes dynamically and the merchant grants access.» The install succeeds either way.

Then a second gate — the strongest line in the documentation for anyone stuck here. «By default, apps don't have access to any protected customer data.» Declaring the scope is not enough: «You can add the relevant scopes to your app, but the API won't return data from non-development stores until your app is configured and approved for protected customer data use.» App installed, scopes declared, data not arriving. How long that approval takes is not documented anywhere we could find, so we are not going to tell you.

The 200 OK that isn't a success

This is the case that makes software look like it is working, and it is worth naming exactly which case it is: protected customer data. Shopify: «GraphQL requests to unapproved types will return an HTTP 200 Ok response with an error message in the errors hash.» The example message begins «This app is not approved to access the Customer object», and in Shopify's own sample the field comes back as null. What is documented here is an unapproved protected-customer-data type, not a missing read_orders scope.

The denial is real, and it is in the body. Shopify warns about the trap itself elsewhere: «In GraphQL, you can't always rely on HTTP status codes to determine whether a query or mutation completed without errors», with the instruction to «parse errors returned in GraphQL responses with a status of 200 OK». Anything checking only the status sees a success with nothing in it.

The 60 days that look like a quiet month

The other silent case is not a permission failure at all. Shopify: «Only the last 60 days' worth of orders from a store are accessible from the Order resource by default.» Going back further is its own request: «If your app is granted access, then you can add the read_all_orders scope to your app along with read_orders or write_orders.» Another approval, not a checkbox.

No error is documented for this. The older orders are simply not there — and fewer rows than expected is exactly what a slow month looks like, which is why this one can go unnoticed.

And now the two that do shout

On BigCommerce, stop hunting for hidden causes and read the status code. 403 is «Returned when permissions do not allow the operation», and the first cause listed for it is «App lacks required OAuth scopes». The 401 there is reserved for credentials: «This response is sent when your client failed to provide credentials or its credentials were invalid.» Two codes, two diagnoses.

WooCommerce tells you too, but first correct one assumption. WooCommerce does not separate listings from orders at all. The permission belongs to the API key and applies to the verb, not the resource: creating the key under WooCommerce > Settings > Advanced > REST API you pick Read, Write or Read/Write — Read «allows the application to retrieve data from your store», Write «allows the application to create and update data».

The check runs on the HTTP method. GET and HEAD pass with read or read_write; POST, PUT, PATCH and DELETE need write or read_write, and without it you get woocommerce_rest_authentication_error, status 401, message «The API key provided does not have write permissions.» So the break there is not listings against orders: every read succeeds, and the first write fails.

One twist. Permissions and credentials share that 401, and the example the documentation puts beside it is the wrong one: «401 Unauthorized — Authentication or permission error, e.g. incorrect API keys». «Permission» is in the sentence, but what you read is «incorrect API keys», so the error sends you off to regenerate credentials that were never wrong. The number is ambiguous. The message text is not.

The one table worth keeping open

What to do with all this

• Do not trust a single green light. Test a read of orders and a write separately — one result cannot stand in for the other.
• Read the body, not just the status. Shopify says exactly that about its own GraphQL API.
• Old orders missing while recent ones arrive is the 60-day window, not a fault.
• On BigCommerce the code is the diagnosis: 403 for scopes, 401 for credentials. On WooCommerce both live under 401 — read the sentence, not the number.

Where we fit, and where we do not

The honest half first. No third-party software can grant itself a permission a merchant has not given, and none of us can speed up an approval that belongs to Shopify. And if you run one store, write code, and only need to read your own orders, you do not need to buy anything: every page quoted here is public and free.

DropMind sits downstream of all this. It publishes to five channels — eBay, Shopify, WooCommerce, Etsy and BigCommerce — so connecting a store is something you do once per channel. This article exists so that the once goes cleanly, and so a quiet week gets read as what it is: sometimes a quiet week, sometimes a scope.

Where this comes from

Every quoted line above is the platform's own, read on 1 September 2026 on the pages below, and nothing from forums or agency posts. That matters here: some of the most repeated claims about this problem do not appear on any official page.

Two limits, stated rather than hidden. eBay belongs in this article and is not in it: its developer pages timed out on every attempt to open them, and we do not quote pages we have not read. And we found no official figure for how long an approval takes or how often any of this happens — the 60 days and the status codes are the only numbers in the piece, both from official tables. This documentation is rewritten often: if a line here decides something for you, open the source.