Shopify or WooCommerce Returning 429: Building a Sync That Doesn't Get Throttled

Shopify's 429 is a documented mechanism: the REST Admin API uses a leaky bucket of 40 requests per app per store on standard plans, and a 429 response carries a Retry-After header telling you how many seconds to wait. WooCommerce is the opposite case - core does not rate limit the REST API, so a 429 there almost always comes from the host or a WAF.

Two different models on one platform

Shopify operates two separate limiting systems, and confusing them is the most common reason a developer "fixes" a 429 that keeps coming back.

The practical difference: on REST the request is the unit, so pulling 500 products one at a time drains the bucket even though each call is tiny. On GraphQL the cost is derived from how many fields and connections you asked for, so one over-broad query can blow the budget by itself.

Why does WooCommerce return 429 when WooCommerce has no rate limit?

Because the limit is not coming from WooCommerce. A WooCommerce store runs on WordPress, which runs on a web server, which usually sits behind a protection layer. Any of those can return a 429, and none of them knows anything about your store logic.

• The host. Nginx or Apache limiting rules on wp-json paths and on admin-ajax.php.
• A security plugin or WAF. Blocks applied to specific paths, sometimes with no Retry-After header at all.
• The Store API. This is the one layer where WooCommerce does document a rate limit of its own - a default of 25 requests in a 10-second window, on POST requests only, and disabled by default. It returns RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset and RateLimit-Retry-After headers.

So diagnosis on WooCommerce starts from a different question entirely: not "how do I slow the sync down" but "who returned this 429". The answer is visible in the response body - a native WordPress error looks nothing like a WAF block page.

Reading the state instead of guessing it

• On Shopify REST, read X-Shopify-Shop-Api-Call-Limit on every response. A value of 38/40 means two requests of headroom, and you can slow down before being throttled rather than after.
• When a 429 arrives, honour Retry-After exactly as given. That is the number of seconds the platform itself is asking for, and it beats any formula you invent.
• On GraphQL, read throttleStatus on every response: maximumAvailable, currentlyAvailable and restoreRate give you the whole budget picture.
• Keep requestedQueryCost alongside actualQueryCost. A wide gap means you are requesting pages larger than what comes back.
• On WooCommerce, log the status code together with the raw response body and every header. Without that you cannot separate a server block from a Store API limit.

How do you build a sync that survives a 429?

1. Separate collection from processing. One process fetches and writes to a queue, another consumes it. A sync that does both in one loop stops entirely on the first 429.
2. Give every queue item an attempt counter and a next-attempt time. Retry-After is written into that next-attempt time, not into a sleep that blocks the whole worker.
3. Run a single worker per store. The Shopify bucket is per app per store, so two parallel workers split the same budget and hit the wall sooner.
4. Use cursor-based pagination and persist the cursor. A sync that restarts from the beginning after every failure spends its budget re-fetching what it already had.
5. Make writes idempotent. After a 429 you do not know whether the request was blocked before or after the update landed, and without a unique key per operation you create duplicates.
6. Record the actual rate, not the intended one. Requests genuinely sent per minute is the only number you can tune against.

What actually breaks

• A fixed sleep. Works in isolation, fails the moment a second app or a human in the admin draws on the same bucket.
• Ignoring Retry-After. An immediate retry extends the throttle rather than shortening it.
• Running in parallel "to speed it up". Doubles consumption, reaches 429 faster, and completes no more work.
• One enormous GraphQL query. Fails on the 1,000-point ceiling rather than the per-second budget, so slowing down will never fix it.
• Treating 429 as fatal. The process dies, somebody reruns it from the start, and the cycle closes.
• Syncing everything every run. A full pull instead of changes since the last timestamp is the fastest way to exhaust a budget.

Diagnosing a stalled sync in five minutes

1. Pull the full status code and every response header for the failed request out of your logs. Without the headers there is no diagnosis.
2. On Shopify, look at X-Shopify-Shop-Api-Call-Limit on the requests immediately before the failure. If it was already near the ceiling, this is a pacing problem rather than a bug.
3. Check whether Retry-After is present at all. Its presence indicates a declared platform limit; its absence suggests an infrastructure-layer block.
4. Count how many requests actually went out in the minute before the failure. That number, not the intent expressed in the code, is what the platform measured.
5. Check who else was working against the same store at that moment - another app, a second worker, or a human exporting data from the admin.
6. On GraphQL, compare requestedQueryCost with actualQueryCost on the last successful calls. A high requested cost is the signal that your pages are too large.

The order matters, because the first four steps separate three problems that look identical from the outside: too high a rate, too expensive a query, and a block that has nothing to do with the store at all.

Related: What API rate limiting is, Shopify vs WooCommerce, Connecting an online store to an ERP.

Sources

• Shopify - REST Admin API rate limits
• Shopify - API rate limits (GraphQL cost model)
• WooCommerce - Rate limiting for Store API endpoints