Shopify GraphQL rate limits are not a single number you can memorize. They are a cost-based system that scores every query, tracks a point bucket per app and per store, and refuses execution the moment your request costs more than you have left.
If you build apps, ERP connectors, or data syncs on Shopify, you will meet this system early. Treat it like a REST endpoint and fire concurrent requests, and you hit a wall of 429 errors fast.
This guide breaks down how the system works, how to read your usage in real time, and how to engineer around the limits instead of fighting them.
Why Shopify Uses Calculated Query Cost
REST rate limiting counts requests. Every call costs the same, whether it reads one field or a thousand. That model wastes capacity and punishes efficient clients.
Shopify moved the GraphQL Admin API to a calculated query cost model instead. The server scores each query by complexity before running it. Cheap reads cost little. Heavy nested queries and mutations cost more.
This design rewards lean queries. You can run many small, cheap queries or a few expensive ones. The choice is yours, as long as you stay inside your point budget.
If you are new to the API surface itself, start with our Shopify GraphQL API guide, then return here to go deep on the limits.
How Query Cost Is Calculated
Shopify runs static analysis on your query before execution. Each field type carries a fixed point value. The total is deterministic, so you can predict cost before you ship.
Here is how the point system breaks down.
| Field type | What it represents | Cost |
|---|---|---|
| Scalar / enum | A final value (id, title, email, boolean) | 0 points |
| Object | A single related object (order.customer) | 1 point |
| Connection | A paginated list (products, orders, variants) | 2 points + 1 point per returned item |
| Mutation | A write that creates, updates, or deletes | 10 points |
Mutations cost more because they trigger side effects. They write to databases, update indexes, and can fire webhooks or emails. That load justifies the higher price.
Every response returns an extensions.cost object. It reports both the requested cost (from static analysis) and the actual cost (measured during execution). The actual cost is often lower than requested.
You can add the Shopify-GraphQL-Cost-Debug=1 header to get a field-by-field breakdown during development.
Shopify GraphQL Rate Limits by Plan
Rate limits scale with your Shopify plan. The bucket holds your maximum balance. The restore rate refills it every second.
| Plan tier | Bucket size | Restore rate |
|---|---|---|
| Standard (Basic, Shopify, Advanced) | 1,000 points | 50 points/sec |
| Shopify Plus | 2,000 points | 100 points/sec |
Three facts matter here.
First, every plan caps a single query at 1,000 points. Plus stores get a deeper bucket, not bigger queries. A query that asks for 250 products with 100 variants each can blow past that ceiling without anyone noticing.
Second, the restore rate is per second, not per minute. That makes sustained throughput predictable. At 50 points per second, you can run roughly one typical order query per second without throttling.
Third, the bucket is scoped to each app and store combination. Calls from one app do not affect another app on the same store. Calls to one store do not affect another store from the same app.
If you are deciding whether the bigger bucket is worth it, our breakdown of Shopify vs Shopify Plus covers the trade-offs for high-volume integrations.
The Portability Trap
Building a 1,500-point query for a Plus store feels safe. It is not. Install that same app on a standard store, and it fails instantly.
If you build public apps or integrations that span multiple merchant tiers, cap your maximum query cost at 1,000 points. Rely on pagination, even when the target store runs Plus today.
Reading Your Rate Limit State
Every GraphQL response includes a full snapshot of your throttle status inside the extensions.cost object.
The throttleStatus block reports three fields: maximumAvailable (your bucket size), currentlyAvailable (points left right now), and restoreRate (refill speed). Read these on every response.
Do not wait for a 429 to react. Check currentlyAvailable against your next query’s cost before you dispatch. If you lack the points, sleep the worker until the bucket refills.
Feed these values into a dashboard like Datadog, Honeycomb, or a simple Postgres table queried by Grafana. You then catch rate limit regressions before merchants complain. Strong Shopify webhook monitoring practices apply here too.
Engineering Patterns for Shopify API Throttling
Avoiding throttling is mostly about architecture, not luck. These patterns keep production apps stable.
1. Request Only the Fields You Need
If you only need a product title, do not request the description and all 50 images. Trimming fields cuts both cost and bandwidth. This is the cheapest optimization available, and it compounds across millions of calls.
Our deeper dive on Shopify GraphQL query cost optimization walks through this field by field.
2. Run a Local Token Bucket Queue
Mirror Shopify’s bucket in your own infrastructure, usually with Redis. Before dispatching a query, check your local bucket. Sleep the worker if points are short, instead of relying on a 429 round trip.
This pattern smooths bursts and keeps you below the ceiling. A solid Shopify queue infrastructure is the backbone of any high-volume sync.
3. Back Off Cleanly on 429
When you do get throttled, the response tells you how long to wait. Use exponential backoff with jitter so retries do not stampede. Read the cost data to time the retry precisely rather than guessing.
4. Cache Data That Rarely Changes
Caching prevents your app from asking for the same data twice in a short window. Cache responses that change slowly, like shop settings or collection structures. Our guide to caching strategies for Shopify GraphQL covers TTLs and invalidation.
5. Prefer Webhooks Over Polling
Polling burns points on data that has not changed. Subscribe to the change events you care about and poll only as a fallback. Reliable Shopify webhook consumers eliminate most of the read traffic that drives throttling.
6. Paginate Deliberately
Connections cost 2 points plus 1 per returned item. Smaller page sizes lower per-query cost but add round trips. Larger pages cost more per call but reduce total requests. Tune the page size to your bucket. Our Shopify GraphQL pagination guide explains cursor-based paging in detail.
When to Switch to Bulk Operations
Single queries cap at 1,000 points. Some datasets simply cannot fit. That is what the Bulk Operations API exists for.
Bulk operations run asynchronously. You submit a query, Shopify processes it in the background, and you download a file with the result. They have no max cost limit and no per-query rate limit.
Use this simple rule set to decide.
| Dataset size | Recommended approach |
|---|---|
| Under 1,000 records | Synchronous paginated GraphQL queries |
| Over 1,000 records | Bulk Operations API |
| Deeply nested connections | Bulk Operations API |
| Real-time, small reads | Standard GraphQL queries |
A bulk query can return a hundred thousand products or more. It takes longer to process, but it does not touch your point bucket. For large extractions, this is the only sane path. Our guide on the Bulk Operations API at scale covers polling, status checks, and file handling.
Common Mistakes That Trigger Throttling
After reviewing many Shopify apps, the same errors show up again and again.
Treating GraphQL like REST is the biggest one. Firing concurrent paginated requests ignores the shared bucket and triggers 429s in seconds.
Ignoring the cost object is next. Apps that never read throttleStatus fly blind and only react after failure.
Over-fetching fields inflates cost silently. A query that requests every field on every variant can quietly cross the ceiling.
Splitting one query into ten small ones can backfire too. Each request carries base overhead, so fragmenting work sometimes raises total cost rather than lowering it.
Missing the userErrors array is a quieter trap. The GraphQL API often returns HTTP 200 even when a mutation fails validation. Iterate over userErrors to catch failures that the status code hides.
Handling Errors the GraphQL Way
GraphQL status codes differ from REST. The API can return 200 OK in cases that REST would flag as 4xx or 5xx. The real detail lives in the response body.
When you exceed your points, you get a throttled message inside the response, often alongside a 429. Parse the body, read the cost data, and retry on schedule.
Building this resilience into your middleware layer pays off. Our guide to resilient Shopify middleware shows how to centralize retry, backoff, and cost tracking so every service inherits the same safety net.
Putting It Together: A Survival Architecture
The architecture that consistently survives Shopify API throttling in 2026 follows a clear shape.
Webhooks come first. Subscribe to every change event you care about and treat polling as a fallback only. This removes most read pressure.
A local token bucket queue governs every outbound call. Workers check available points before dispatch and sleep when the bucket runs low.
Bulk operations handle anything over 1,000 records. Synchronous queries stay lean and field-trimmed.
Observability sits across all of it. Every response feeds throttle telemetry into a dashboard so you spot regressions early.
If you run a high-traffic store or app, pair these patterns with a broader scaling Shopify apps to millions of requests strategy and a proven async Shopify architecture.
Conclusion
Shopify GraphQL rate limits reward engineers who respect the cost model. Read the extensions.cost object on every response. Queue your calls against a local bucket. Trim your fields. Reach for bulk operations when data outgrows a single query.
Get those four habits right, and the Shopify API quota stops being a wall and becomes a budget you plan around. Throttling errors fade, syncs stay reliable, and your app scales cleanly across every merchant tier.
If you want hands-on help architecting a throttle-resistant integration, the team at Kolachi Tech builds and audits Shopify systems for exactly this.
FAQs
What is the Shopify GraphQL rate limit? Standard plans get a 1,000-point bucket that refills at 50 points per second. Shopify Plus gets a 2,000-point bucket refilling at 100 points per second.
How is GraphQL query cost calculated? Scalars cost 0 points, objects cost 1, connections cost 2 plus 1 per item, and mutations cost 10. Shopify scores the query before running it.
Why am I getting 429 errors on the GraphQL Admin API? Your queries are costing more points than your bucket holds. Read the cost object, queue your calls, and back off when points run low.
When should I use Bulk Operations instead of normal queries? Use bulk operations for any dataset over 1,000 records or deeply nested connections. They bypass the point bucket and per-query cost limits.
Does Shopify Plus let me run bigger single queries? No. Every plan caps a single query at 1,000 points. Plus gives you a deeper bucket and faster restore, not larger queries.
How do I read my current rate limit usage? Check the extensions.cost.throttleStatus object on every response. It reports your maximum, currently available points, and restore rate.
