October 10, 2026 · Muhammad Rehan · More by Muhammad Rehan
Customer Account API: Two Rate Limits, Two Failure Modes
Shopify's Customer Account API now enforces two independent rate limits — one returns HTTP 429, the other hides inside a 200 OK response.
Two Limits, Not One
On October 7, 2026, Shopify's changelog announced a new rate limit for the Customer Account API: a per-customer cap of 3,000 requests per minute per store, shared across every app installed on that store. It applies in addition to — not instead of — the API's existing cost-based limit.
That existing limit works differently. The Customer Account API is rate-limited by calculated query cost: a quota of 7,500 cost points per app, per store and customer, replenished at 100 points/second on Standard, 200 points/second on Advanced Shopify and Shopify Plus, and 400 points/second on Shopify for enterprise (Commerce Components). Most fields cost 1 point and most mutations cost 10, and every response reports requestedQueryCost and actualQueryCost under extensions.
Same Error Code, Different HTTP Status
Both limits raise a THROTTLED error, but they signal it differently. Exceed the cost-based quota, and the API returns HTTP 200 OK with the THROTTLED error sitting in the response body. Exceed the new per-customer limit, and the API returns HTTP 429 Too Many Requests, with a Retry-After header telling you how long to wait.
That distinction matters because it's easy to write retry logic that checks only for status === 429. Shopify's own changelog recommends exactly that pattern for the new limit: detect 429, read Retry-After, wait, retry. Followed literally, that logic will catch the per-customer throttle every time — and never notice the cost-based one, because a 200 OK response looks successful to any code that isn't also inspecting the body for errors.
The Shared-Limit Wrinkle
The per-customer limit has one more property worth knowing: it's shared. It isn't 3,000 requests per app — it's 3,000 requests per customer per store, pooled across every app that store has installed. A storefront running a loyalty app, an order-history widget, and a headless frontend that all call the Customer Account API for the same logged-in customer are drawing from the same bucket. None of them individually needs to look abusive for one of them to start seeing 429s.
For any app calling the Customer Account API, the practical fix is the same either way: don't rely on HTTP status alone. Check the response body's errors and extensions for a THROTTLED code regardless of status, and when you do see 429, read Retry-After before retrying rather than guessing at a backoff interval.