Anyone who has run a large import, synced stock across channels or processed a flash-sale rush on Shopify has met the message: throttled, rate limit exceeded, try again. It tends to appear at the worst time, during peaks, and it can break automations in quiet ways: a step fails, nobody retries it and an order or a stock update is lost. Rate limits are not a bug or a punishment. They are how a shared platform protects itself, and an automation that ignores them will eventually fail.
This guide explains how Shopify’s rate limits work in plain terms and how to design automations that cope with them. It draws on Shopify’s developer documentation, read on 20 October 2026; the exact numbers vary by API and plan and change over time, so where the documentation does not give a figure we do not invent one. It is useful whether you build workflows yourself, hire someone to build them or use tools such as Zapier, Make or n8n, which all sit on top of these APIs. It connects to the event-handling in Shopify webhooks explained and the burst handling in inventory sync across sales channels.
The leaky bucket in one picture
Imagine a bucket with a small hole. Each API request pours some water in. Water drains out through the hole at a steady rate. As long as you add water more slowly than it drains, the bucket never fills. You can pour a burst in quickly, because the bucket has room, but if you keep pouring faster than it drains, it overflows, and Shopify returns a throttle error until enough has drained. Shopify’s documentation describes most of its limits this way: a bucket that drains at a restore rate, and a full bucket that triggers an error.
| Idea | What it means | Practical effect |
|---|---|---|
| Bucket size | How much you can send in a burst | Short spikes are fine |
| Restore rate | How fast capacity returns | Sustained load is limited to this pace |
| Throttle error | The bucket is full or a single request is too expensive | Wait, then retry |
| Plan differences | Limits can differ by plan and API | Check the current documentation for yours |
Shopify also notes that it may temporarily reduce rate limits to protect platform stability. A design that relies on running exactly at the limit is therefore fragile; leave headroom.
GraphQL: limits based on query cost
Shopify’s GraphQL Admin API does not count requests; it assigns each query a calculated cost, based roughly on how much data it asks for, and limits the points you can spend. Every response reports the cost of the query and the state of your bucket, and Shopify documents a maximum cost for a single query, which at the time of reading was 1,000 points. A query that costs more than that is rejected outright, however empty the bucket is.
- Ask for only what you need. Requesting fifty fields on every order costs far more than requesting five.
- Limit the size of lists. A smaller page of results costs less; paginate instead of asking for everything.
- Read the cost data. The response includes the requested cost, the actual cost and the bucket’s available points and restore rate, so a well-built tool can pace itself.
- Watch the two error types. A single query that is too expensive returns a cost-exceeded error; a bucket that is empty returns a throttled error. They need different fixes: shrink the query, or wait.
REST: limits based on requests
The older REST Admin API uses a request-based bucket with headers that tell you how much room is left. Many existing tools still use it, and its behaviour is the same in spirit: bursts are tolerated, sustained overload is not. Shopify’s documentation steers newer development toward GraphQL, so check its current guidance when choosing how to build a new integration.
Other limits that surprise people
| Limit (from Shopify’s documentation) | What it means | Who it affects |
|---|---|---|
| New variant creation | Stores with 500,000 or more product variants can create at most 10,000 new variants per day; Shopify Plus stores are exempt | Large catalogue imports |
| Array input size | Input arrays accept at most 250 items | Bulk updates in one call |
| Pagination depth | Pagination caps at 25,000 objects | Reading very large lists |
| Customer Account API | A separate per-customer, per-minute limit applies | Customer-facing apps |
| Recommended backoff | One second after a throttle | All retrying clients |
Read from Shopify’s developer documentation on 20 October 2026. Check the page for current numbers.
What happens in your store when a limit is hit
A throttle error is only a problem if the caller handles it badly. A good caller waits and tries again; a bad one gives up, loses the update and carries on as if nothing happened. The visible symptoms in a store are familiar.
- Missing updates. An order never reaches the warehouse, a stock change is not applied on another channel.
- Half-finished imports. A large product upload stops partway and leaves a mixture of old and new data.
- Slow syncs. Everything works, but an hour late on busy days.
- Duplicate effects. A retry without a key creates a second action; see Shopify webhooks explained for the idempotency rule.
- Silent failure. Nothing is logged, nobody is told and the gap is discovered by a customer.
Design habits that survive the limits
Queue the work and pace it
Put every API job on a queue, and let a worker take jobs at a rate that fits the limit. A burst of events, such as hundreds of orders in a sale, fills the queue instead of overflowing the bucket, and the worker drains it steadily. The queue also gives you a place to see how far behind you are.
Back off and retry
When you are throttled, wait, then retry. Shopify recommends a backoff of about one second after a throttle, and a sensible client lengthens the wait on repeated failures and adds a little randomness, so that many workers do not retry at the same instant. Set a maximum number of attempts and, after that, move the job to a failed list and alert a person with the job and the reason.
Batch and use bulk operations
Many small calls cost more than a few large ones. Combine updates where the API allows, within the documented limits on input size. For large reads and writes, such as exporting every product or updating thousands of prices, Shopify offers bulk operations that run on its side without consuming your bucket call by call. They are the right tool for catalogue-wide jobs.
Prefer events to polling
Asking Shopify every minute whether anything has changed spends the bucket on empty answers. Subscribe to webhooks, so Shopify tells you when something changes, and keep a slower scheduled check as a safety net. The combination uses far fewer calls and reacts faster.
Request less
Trim queries to the fields you use and filter on the server side instead of fetching everything and filtering in your tool. Cache data that rarely changes, such as shipping zones, locations or tax settings, instead of reading it for every order.
Reconcile and alert
Because failures will happen despite good design, run a scheduled job that compares what should have happened with what did, and fixes the difference. Alert when the retry queue grows beyond a threshold or when a job hits its attempt limit. A growing queue is an early warning that you are pushing harder than the platform allows.
Choosing tools with limits in mind
| Question for your tool or builder | Good answer |
|---|---|
| What happens when Shopify throttles a call? | It waits and retries, then alerts after a set number of attempts |
| Do you use webhooks or polling? | Webhooks for speed, polling or reconciliation as a safety net |
| How do you handle bursts such as sales? | A queue that smooths them and a visible backlog |
| How are large imports done? | Bulk operations or batches that respect documented limits |
| How do I know a call failed? | An alert naming the job, the record and the reason |
| What if limits change? | Pacing is read from response data, not hard-coded |
No-code tools handle some of this for you and not all. They typically retry throttled calls, but they may do so a limited number of times, they bill every retry as usage in some cases and they do not give you a queue you can inspect. Our comparison of Zapier, Make and n8n touches on how each behaves under load.
A worked example
A store runs a flash sale and receives 1,200 orders in an hour. Its stock sync makes three API calls per order: read the order, adjust stock for each item and tag the order. That is 3,600 calls in an hour, which is one a second, well within a bucket that tolerates bursts, but the calls arrive unevenly: 400 orders in the first ten minutes. Without a queue, the first ten minutes produce a wall of throttle errors, and about a quarter of the stock updates are lost. With a queue that paces calls and retries after a one-second backoff, the backlog peaks at a few hundred jobs, clears within twenty minutes and nothing is lost. The only change is design: queue, backoff, retry and an alert on queue length. The numbers are illustrative; the pattern is what to copy. It is the pattern behind our inventory sync and ecommerce workflow automation builds.
Sources and further reading
Figures and rules in this guide come from the primary pages below. Platform limits and prices change, so open the page before you build on a number.
- Shopify developer docs: API rate limits, leaky bucket, variant limit, input and pagination limits, backoff, read 20 October 2026
- Shopify developer docs: GraphQL Admin API, query cost and throttle status fields
- Shopify developer docs: webhooks, events instead of polling