I’m seeing an unusual issue with one of our merchant stores and was wondering if anyone has experienced something similar.
Our app is receiving an HTTP 423 response when attempting to retrieve order data via the Shopify Admin API. At the same time, requests indicate that the shop is unavailable.
However:
The Shopify storefront is online and accessible.
There are no warnings or issues shown in the Shopify Partner Dashboard (e.g. cancelled payments, frozen store, suspended app access, etc.).
This issue appears to be affecting only this specific store.
Has anyone come across a situation where Shopify returns a 423 for API requests even though the store is operational?
Are there any other account states or platform conditions that could cause this response which aren’t surfaced in the Partner Dashboard?
Hi @daryl. Yes, other shop account states can cause an HTTP 423 response but aren’t surfaced in the Partner Dashboard due to their nature. These states are usually temporary though.
To add some practical handling on top of Paige’s answer, since 423 is one of those responses you mostly have to live with rather than fix:
We treat 423 as a shop-level pause rather than a request-level failure. When we get one, we stop hitting that shop entirely for a backoff window (we start at fifteen minutes and grow it, capping at a few hours) instead of letting individual jobs keep retrying, because retrying per-request just burns your rate limit and fills your error logs with noise for a shop that genuinely cannot serve you right now. Everything queued for that shop gets parked and replayed after the shop comes back, and any webhook payloads that arrive in the meantime get stored so you’re not relying on backfilling from the Orders API later.
The important part is that 423 is not the same class of problem as 401 or 402. It doesn’t mean your access token is bad and it doesn’t mean you should uninstall or re-auth, so make sure whatever handles it in your code doesn’t lump it in with auth failures and tear down the connection — we’ve seen apps mark a merchant as churned because a temporary lock got interpreted as revoked access, and then the merchant has to reinstall for no reason.
It’s also worth surfacing it honestly in your own UI. Something like “we’re temporarily unable to sync with your store, we’ll resume automatically” saves a support ticket and stops the merchant assuming your app is broken. In our experience these clear on their own within hours, so if it persists for more than a day on one specific shop it’s worth having the merchant open a ticket from their admin, since they’ll get a straight answer about their own shop’s state faster than you will as a third party.