Executive summary
- What: The Customer Account API now caps any single customer on a store at 3,000 requests per minute, counted across every app installed on that shop.
- Why: It is a second, independent guardrail alongside the cost based quota, and it fails differently: an HTTP 429 rather than a 200 carrying a GraphQL error.
- Who: Teams running headless account areas, customer account UI extensions, or any app reading buyer data on the storefront. Retry logic deserves a look.
What changed
Shopify has layered a request count limit on top of the Customer Account API's cost based control. The cost model is unchanged: queries are priced in points against a 7,500 point quota per app, per store and customer, refilling under a leaky bucket at 200 points per second on Plus and 400 on Shopify for enterprise.
The new limit counts requests rather than cost. Any one customer on a store gets 3,000 requests per minute, and that budget is shared across every app on the shop rather than allocated per app. Two apps polling the same buyer draw down one pool.
The failure mode is the detail worth internalising. Exceeding the cost quota returns HTTP 200 with a THROTTLED error inside the GraphQL errors array. Exceeding the per-customer limit returns HTTP 429, also THROTTLED, plus a Retry-After header giving the seconds to wait. A client that only inspects the GraphQL error body catches the first case and silently mishandles the second.
Why it matters
For most Plus merchants this is a non event in steady state: a buyer signing in, reviewing an order and updating an address generates tens of requests, not thousands. The exposure sits in the architecture, not the traffic.
Three patterns push a single customer toward the ceiling: a headless account area that refetches on every route change with no caching, polling loops such as a widget checking fulfillment status every few seconds, and app sprawl where loyalty, subscription and returns portals all read the same buyer record on one page load.
Because the budget is shared, the app that trips the limit is often not the one that caused the pressure, and the buyer sees a broken account page either way. A third party app you did not build can degrade an experience on your own storefront. If you are weighing the platform's account options, our breakdown of new customer accounts versus classic accounts is a useful companion read.
Role-specific impact
- Marketers: No campaign change. Account page errors during a promotion read as a site outage in support tickets, so include the account area in launch day monitoring.
- Developers: Audit every caller for 429 handling, honour Retry-After, and treat the 200 and 429 THROTTLED cases as distinct branches. Cache and debounce buyer data fetches.
- Store admins: Keep an inventory of installed apps touching customer accounts. A shared budget means app count carries a direct technical cost, which helps when pruning the stack.
Use-case example
Real-world scenario
A B2B distributor runs a headless reorder portal on Shopify Plus, refetching order history, saved addresses and company location data on every tab switch. A purchasing manager comparing a dozen past orders produced roughly 400 requests per session, comfortably inside the limit. The team then shipped a shipment status widget polling every two seconds, which alone generated about 1,800 requests per minute. Combined with a loyalty app reading the same record, that account crossed 3,000 and began returning 429s mid session. Caching order history for 60 seconds and widening the widget to 30 seconds cut peak per-buyer volume by roughly 85 percent and ended the throttling.
Implementation checklist
- Inventory every surface calling the Customer Account API: headless account pages, UI extensions, custom apps and third party apps.
- Add explicit 429 handling to each client: read Retry-After and wait that many seconds, falling back to capped exponential backoff with jitter if the header is absent.
- Separate the two throttle branches, since a 200 THROTTLED signals cost pressure and a 429 signals request count pressure.
- Replace polling with webhooks where an event exists, widen intervals where polling is genuinely required, and cache buyer data that is stable within a page session.
- Instrument 429 rates per surface so throttling can be attributed to a specific app rather than guessed at.
FAQ
Q: Does this replace or change the cost based rate limit on our plan?
A: No. The cost point quota and your plan's restore rate are untouched. The per-customer limit applies in addition, so a request can now be rejected for either reason.
Q: Will ordinary shoppers realistically hit 3,000 requests per minute?
A: Not in a well behaved implementation. The limit is reached through polling, uncached refetches or several apps querying one buyer at once, so the fix is architectural rather than a request for more quota.
Resources
Customer Account API rate limits
Need guidance? Talk to Makro.