How the Shopify throttle actually works

The Shopify Admin API uses a leaky-bucket model. Each app has a bucket that refills at a fixed rate; every call costs points, and when the bucket is empty you are throttled until it refills. GraphQL costs are calculated from the query, so a request that asks for more data costs more, and a badly shaped query can drain the bucket in a handful of calls.

The practical consequence is that throughput is governed by query design, not just call count. A list query that pulls nested line items and metafields for 250 orders is far more expensive than four narrower queries.

When polling stops scaling

Polling for changes is fine at low volume. As order rate climbs, the interval you need to stay current drops below the point where each poll completes before the next is due, and you spend your quota asking “anything new?” instead of moving data.

A webhook-driven design inverts this: Shopify tells you when something changed, and you spend quota only on the records that did. Below a few hundred orders a day the difference is academic; above it, webhooks stop being optional.

Bulk operations for historic loads

For the initial back-fill — every historic order into the accounting system, say — use the Bulk Operations API. It runs the query server-side and hands you a single file, which is both faster and dramatically cheaper than paginating the same data through the standard API.

A design that respects the limit

Webhooks for change events, bulk operations for back-fill, narrow queries for everything else, and a token-bucket client that backs off on the throttle response rather than retrying blindly. With those four in place, rate limits stop being something you think about.