Shopify API rate limits by plan: GraphQL query cost points, the REST leaky bucket, bulk operations and how to stop THROTTLED errors

What are the Shopify API rate limits?

The GraphQL Admin API limits you by calculated query cost rather than request count, in points per second: 100 on a Standard plan, 200 on Advanced Shopify, 1,000 on Shopify Plus and 2,000 on Enterprise. On top of the rate, no single query may cost more than 1,000 points. The legacy REST Admin API uses a different model entirely, a leaky bucket holding 40 requests that refills at 2 per second, raised by a factor of ten for Plus stores.

The shift from counting requests to pricing them is the part that catches teams migrating from REST. Under REST you could reason about throughput in requests per second and size a job accordingly. Under GraphQL, two jobs that issue the same number of requests can consume wildly different budgets, because a query asking for orders with their line items, their fulfillments and every metafield on each costs a multiple of one asking for six scalar fields. Throughput becomes a property of your query, not your schedule.

Shopify API rate limits by plan

Shopify GraphQL Admin API points per second and REST Admin API bucket limits by plan

Plan	GraphQL Admin API	REST Admin API	What to know
Standard	100 points/second	40 bucket, 2/second	The default most stores integrate against. A single query still cannot exceed 1,000 points
Advanced Shopify	200 points/second	40 bucket, 2/second	Double the GraphQL rate of Standard. Enough to change how long a nightly backfill takes
Shopify Plus	1,000 points/second	x10 multiplier	Ten times Standard on GraphQL, and the REST bucket is raised by a factor of ten as well
Enterprise	2,000 points/second	x10 multiplier	Commerce Components. At this rate the constraint is almost always query design, not the plan

How is Shopify GraphQL query cost calculated?

Shopify assigns each field in a query a cost, sums them into a requested cost before the query runs, then reports the actual cost after it runs. Both numbers come back on the response along with a throttleStatus object holding maximumAvailable, currentlyAvailable and restoreRate. The requested cost is what gets checked against your remaining budget, so an expensive query is refused before it does any work.

Two practical consequences follow. Requesting a large page and then discarding most of the rows costs you the full requested amount, which is why filtering on the server side is worth far more than filtering in your own code. And because the actual cost is usually lower than the requested cost, a client that only reads the actual figure will consistently underestimate how much budget it is really consuming.

The ceilings that are not rate limits

Several Shopify limits are absolute rather than time-based, which means waiting does not help and neither does upgrading. These are the ones that turn up as a failed migration rather than a slow one.

Shopify absolute API ceilings including query cost, pagination, bulk operations and variant creation

Limit	Value	Detail
Maximum cost of a single query	1,000 points	Exceeding it rejects the query outright rather than throttling it. Deep nesting is the usual cause
Array input maximum	250 items	The cap on any list argument across the APIs, which sets your realistic page size
Pagination ceiling	25,000 objects	You cannot page past it. Beyond that you must filter, split by date, or run a bulk operation
Count accuracy	up to 25,000 items	Counts above this are not exact, so never verify a load by comparing a Shopify count to a row count
Concurrent bulk query operations	5 per app per shop	From API version 2026-01. Before that it was one bulk operation of each type at a time
Bulk operation result URL lifetime	1 week	The signed JSONL download expires. A pipeline that misses the file has to rerun the whole job
Bulk query shape	5 connections, 2 nesting levels	Products to variants is valid. Products to variants to images to metafields is not
New variants per day above 500,000 variants	10,000 per day	A hard ceiling for very large catalogs that turns a one-day migration into a scheduled one

The pagination ceiling deserves particular attention because it fails quietly. A store with more than 25,000 orders in the window you are querying cannot be fully paged, and counts are only accurate up to the same figure. Teams routinely verify a load by comparing a Shopify count to a warehouse row count, decide the numbers match, and never learn that both were capped at the same place.

What does a Shopify THROTTLED error mean?

A THROTTLED error means your requested query cost exceeded the points currently available in your bucket. The query did not run and nothing was written. It clears on its own as the bucket refills at your plan restore rate, so the correct response is to wait for enough points to accumulate and resubmit, not to retry immediately.

This is different from a query rejected for exceeding the 1,000 point maximum, which never succeeds no matter how long you wait, and different again from a REST 429, which tells you the leaky bucket is full but gives you no cost signal to plan against. Distinguishing the three in your error handling is worth doing once, because the remedy is different for each: wait, rewrite the query, or slow the request rate.

How do you avoid Shopify rate limits?

Six changes, in the order they pay off. The first two account for most of the improvement in almost every integration we have looked at, and neither of them costs anything.

Can you increase Shopify API rate limits?

Only by changing plan. Shopify does not sell a rate limit add-on the way some platforms do, so the levers are the plan tier, which moves you from 100 to 200 to 1,000 to 2,000 points per second, and the efficiency of your own queries. For most stores the second lever is both larger and free.

Before you treat a plan upgrade as a fix, work out which limit you are hitting. Upgrading to Plus for ten times the points does nothing for a query that costs 1,200 points, because that is an absolute ceiling. It does nothing for a job stalled at 25,000 objects of pagination. And it does nothing for a backfill that should have been a bulk operation. Log the requested cost and the throttleStatus on every response for a day and the answer will be obvious.

How long are Shopify API versions supported?

Shopify releases a new API version every three months at the start of the quarter, on 1 January, 1 April, 1 July and 1 October at 5pm UTC. Each stable version is supported for a minimum of 12 months, with at least nine months of overlap between consecutive versions. If an app targets a version that is no longer accessible, Shopify falls forward and serves the request using the oldest accessible stable version.

That fall-forward behavior is friendlier than a hard failure and more dangerous because of it. An integration pinned to a retired version keeps working, quietly, against a schema that has moved on, until a field it depends on is gone and a nightly load starts producing nulls nobody notices. Put the version string in your monitoring and treat a version release as a scheduled maintenance item rather than a surprise.

Do Shopify webhooks count against the rate limit?

No. Webhook deliveries are pushed to your endpoint by Shopify and do not consume query cost, which makes replacing a poll with a subscription the cheapest headroom available. The trade is that delivery is best effort, ordering is not guaranteed, and you own retries and deduplication on your side.

The design that holds up in production is webhooks for the events where latency matters, such as order creation and fulfillment, plus a scheduled reconciliation pass that queries records updated since the last successful run. That pass is cheap because it is filtered, and it repairs anything the webhooks dropped without anyone having to notice first. The general trade-off is covered in webhooks versus polling.

How many API calls does a Shopify sync actually use?

Work through the arithmetic before you buy anything, because it is usually reassuring. A nightly incremental pull of orders updated in the last 24 hours from a store doing 2,000 orders a day, requested at 250 per page with a lean field selection, is single-digit queries. Even on a Standard plan at 100 points per second that finishes in seconds. The job that hurts is the first one, the full history load, and that is exactly the job bulk operations exist for.

Which is why the useful question on a vendor demo is not how many connectors they have. It is whether the initial backfill uses a bulk operation, whether the connector reads throttleStatus to pace itself, and which API version it pins. A vendor who cannot answer those three is spending a budget they do not measure. We keep the full set of limits tabled alongside the platforms that have to live inside them on Shopify integration tools.

Where rate limits fit in a working Shopify integration

Rate limits shape three decisions and are irrelevant to the rest. They decide whether you poll or subscribe, whether the backfill is a bulk operation or a paged crawl, and how lean your field selection has to be. The property mapping, the conflict rule and the schedule are unaffected by any of it.

If the destination is accounting rather than a warehouse, a second set of limits applies at the far end and it is usually the tighter one. The Xero API allows 5 concurrent calls, 60 calls per minute and 5,000 calls per day per connected organization, so a tool writing an invoice, a payment and a fee per order runs out of day before a busy store runs out of orders. Summarized journals are the standard answer. The same care applies to the supplier side of the ledger, where cost of goods still arrives as PDF documents somebody has to turn into structured line items before any of it reaches the same books.

For the warehouse direction, where you are reading in bulk on a schedule rather than writing conversationally, the mechanics including the incremental filter that keeps a nightly load small are covered in Shopify to Snowflake and Shopify to BigQuery. For the accounting direction, see Shopify to QuickBooks.