Shopify API rate limits

Shopify APIs use several different rate-limiting methods. They’re described in more detail below, but these are the key figures in brief:

Shopify may temporarily reduce API rate limits to protect platform stability. We will strive to keep these instances brief and rare. However, your application should be built to handle limits gracefully.

All Shopify APIs use a leaky bucket algorithm to manage requests. 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 API request tosses some number of marbles into the bucket.
• Each second, a marble is removed from the bucket (if there are any). This restores capacity for more marbles.
• If the bucket gets full, you get a throttle error and have to wait for more bucket capacity to become available.

This model ensures that apps that manage API calls responsibly can maintain capacity to make bursts of requests when 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.

Shopify's GraphQL APIs use a calculated query cost method. The exception is the the Storefront API, which has no rate limits applied on the number of requests. Learn more.

Apps can make requests that cost a maximum number of points each 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.

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 size and restore rate based on API and plan tier. By making simpler, lower-cost queries, you can maximize your throughput and make more queries over time.

Every field in the schema has an integer cost value assigned to it. The cost of a query is the maximum of possible fields selected. Running a query is the best way to find out its true cost.

By default, a field's cost is based on what the field returns:

Although these default costs are in place, Shopify also reserves the right to set manual costs on fields.

Shopify calculates the cost of a query both before and after execution.

• The requested cost is based on the composition of fields selected in the request.
• The actual cost is based on the query results, and may be lower than requested cost due to the actual objects returned or connections that return fewer edges than requested.

Rate limits use a combination of the requested and actual query cost. Before execution begins, an app’s bucket must have enough capacity for the requested cost of a query. When execution is complete, the bucket is refunded the difference between the requested cost and the actual cost of the query.

A single query may not exceed a cost of 1,000 points, regardless of plan limits. This limit is enforced before a query is executed based on the query’s requested cost.

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 extensions key:

To get a detailed breakdown of how each field contributes to the requested cost, you can include the header Shopify-GraphQL-Cost-Debug=1 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.

The Storefront API is designed to support businesses of all sizes. The Storefront API will scale to support surges in buyer traffic or your largest flash sale. There are no rate limits applied on the number of requests that can be made to the API.

The Storefront API provides protection against malicious users, such as bots, from consuming a high level of capacity. If a request appears to be malicious, Shopify will respond with a 430 Shopify Security Rejection error code to indicate potential security concerns. Ensure requests to the Storefront API include the correct Buyer IP header.

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.

Shopify limits the amount of checkouts that can be created on the Storefront API per minute. If an API client exceeds this throttle, then a 200 Throttled error response is returned. Shopify recommends designing your app to be resilient to this scenario. For example, you could implement a request queue with an exponential backoff algorithm.

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 following GraphQL Admin API types have an additional throttle that takes effect when a store has 50,000 product variants. After this threshold is reached, no more than 1,000 new variants can be created per day.

• productCreate
• productUpdate
• productVariantCreate

If an app reaches API rate limits for a specific resource, then it receives a 429 Too Many Requests response, and a message that a throttle has been applied.

In certain cases, Shopify needs to enforce rate limiting in order to prevent abuse of the platform. Therefore, your app should be prepared to handle rate limiting on all endpoints, rather than just those listed here.

Designing your app with best practices in mind is the best way to avoid throttling errors. For example, you can stagger API requests in a queue and do other processing tasks while waiting for the next queued job to run. Consider the following best practices when designing your app:

• Optimize your code to only get the data that your app requires.
• Use caching for data that your app uses often.
• Regulate the rate of your requests for smoother distribution.
• Include code that catches errors. If you ignore these errors and keep trying to make requests, then your app won’t be able to gracefully recover.
• Use metadata about your app’s API usage, included with all API responses, to manage your app’s behavior dynamically.
• Your code should stop making additional API requests until enough time has passed to retry. The recommended backoff time is one second.