Shopify API rate limits
To ensure our platform remains stable and fair for everyone, all Shopify APIs are rate-limited. We use a variety of strategies to enforce rate limits. We ask developers to use industry standard techniques for limiting calls, caching results, and re-trying requests responsibly.
Compare rate limits by API
Shopify APIs use several different rate-limiting methods. They’re described in more detail below, but these are the key figures in brief:
|API||Rate-limiting method||Standard limit||Shopify Plus limit|
|Admin API (GraphQL)||Calculated query cost||50 points/second||100 points/second|
|Admin API (REST)||Request-based limit||2 requests/second||4 requests/second|
|Storefront API||Time-based limit||minimum 0.5s per request, 60s per user IP||minimum 0.5s per request, 120s per user IP|
|Payments Apps API (GraphQL)||Calculated query cost||910 points/second||1820 points/second|
The leaky bucket algorithm
All Shopify APIs use a leaky bucket algorithm to manage requests. This algorithm lets your app make an unlimited amount of requests in infrequent bursts over time.
The main points to understand about the leaky bucket metaphor are as follows:
- Each app has access to a bucket. It can hold, say, 60 “marbles”.
- Each second, a marble is removed from the bucket (if there are any). That way there’s always more room.
- Each API request requires you to toss a marble in the bucket.
- If the bucket gets full, you get an error and have to wait for room to become available in the bucket.
This model ensures that apps that manage API calls responsibly will always have room in their buckets to make a burst of requests if needed. For example, if you average 20 requests (“marbles”) per second but suddenly need to make 30 requests all at once, you can still do so without hitting your rate limit.
The basic principles of the leaky bucket algorithm apply to all our rate limits, regardless of the specific methods used to apply them.
Rate limiting methods
Shopify uses three different methods for managing rate limits. Different APIs use different methods depending on use case, so make sure you understand the various types of rate limits your apps will encounter:
Apps can make a maximum number of requests per minute. For example: 40 API requests within 60 seconds. Each request counts equally, regardless of how much or how little data is returned.
This method is used by the REST Admin API.
Apps can make requests that take a maximum amount of time per minute. For example: 120 requests within 60 seconds, with each request taking 0.5 seconds to return. More complex requests take longer, and therefore take up a proportionally larger share of the limit.
This method is used by the Storefront API.
Calculated query costs
Apps can make requests that cost a maximum number of points per minute. For example: 1000 points within 60 seconds. More complex requests cost more points, and therefore take up a proportionally larger share of the limit.
This method is used by the GraphQL API
GraphQL Admin API rate limits
Calls to the GraphQL Admin API are limited based on calculated query costs, which means you should consider the cost of requests over time, rather than the number of requests.
GraphQL Admin API rate limits are based on the combination of the app and store. This means that calls from one app don't affect the rate limits of another app, even on the same store. Similarly, calls to one store don't affect the rate limits of another store, even from the same app.
Each combination of app and store is given a bucket of 1000 cost points, with a leak rate of 50 cost points per second. This means that the total cost of your queries cannot exceed 1,000 points at any given time, and that room is created in the app’s bucket at a rate of 50 points per second. By making simpler, low-cost queries, you can make more queries over time.
The limit uses a combination of the requested and the actual query cost. Before execution begins, the app’s bucket must have enough room for the requested cost of the query. When execution is complete, the bucket is refunded the difference between the requested cost and the actual cost of the query.
Every field in the schema has an integer cost value assigned to it. The cost of a query is the sum of the costs of each field. Running a query is the best way to know the true cost of a query.
By default, a field's cost is based on what the field returns:
|Field returns||Cost value|
Although these default costs are in place, Shopify also reserves the right to set manual costs on fields.
Requested and actual cost
Shopify calculates the cost of a query both before and after query execution. The requested cost is based on the number of fields requested. The actual cost is based on the results returned, since the query can end early due to an object type field returning null, or connection fields can return fewer edges than requested.
Single query limit
A single query to the API cannot exceed a cost of 1,000. This limit is enforced before a query is executed based on the query’s requested cost.
Maximum input array size limit
Input arguments that accept an array have a maximum size of 250. Queries and mutations return an error if an input array exceeds 250 items.
The response includes information about the cost of the request and the state of the throttle. This data is returned under the
To get a detailed breakdown of how each field contributes to the requested cost, you can include the header
'X-GraphQL-Cost-Include-Fields': true in your request.
To query and fetch large amounts of data, you should use bulk operations instead of single queries. Bulk operations are designed for handling large amounts of data, and they don't have the max cost limits or rate limits that single queries have.
REST Admin API rate limits
Calls to the REST Admin API are governed by request-based limits, which means you should consider the total number of API calls your app makes. In addition, there are resource-based rate limits and throttles.
REST Admin API rate limits are based on the combination of the app and store. This means that calls from one app don't affect the rate limits of another app, even on the same store. Similarly, calls to one store don't affect the rate limits of another store, even from the same app.
Limits are calculated using the leaky bucket algorithm. All reques