Navigating BigCommerce’s API Rate Limits Update
At BigCommerce, our top priority is providing a platform you can count on, and to make sure everything runs smoothly and efficiently, we use rate limits for our REST APIs.
What does this mean for you?
Simply put, rate limits help manage the number of API calls made, ensuring that the system remains reliable and performs well for everyone. By controlling the traffic, we can prevent any single app from hogging resources. .
In this article, we’ll break down how these rate limits work, why they're important, and share some best practices to help you navigate them effectively. Whether you're just getting started with our APIs or looking to optimize your existing integration, we've got you covered with all the information you need to make the most of BigCommerce’s robust and reliable platform.
* We recommend adhering to industry-standard rate limits when developing.
How Rate Limits Work
Each API request consumes one quota unit, and the system rejects later requests once it reaches the quota. This continues until the quota is refreshed.
All apps accessing the store share the store's quota. This prevents a single app from using the entire quota. The available quota for an app adjusts as other clients make or stop requests.
Rate Limits by Plan Type
Apps using OAuth are rate-limited based on a quota that's refreshed every few seconds. The maximum quota varies by store plan and requested resources.
Plan Type | Quota |
Enterprise and Enterprise-Test | by plan and resource |
Other sandboxes (Dev/Partner/Employee) | by resource |
Pro | 60k per hour (450 / 30sec) |
Plus & Standard | 20k per hour (150 / 30sec) |
Unlimited Rate Plan
The Unlimited Rate Plan is for some BigCommerce Enterprise clients. It has no request rate limits. However, it may face limits from physical infrastructure, capping the maximum request throughput for a resource.
For more on resource constraints, see object-related limits (Help Center).
* BigCommerce can limit excessive API use to keep the platform stable. This is per our Terms of Service.
Best Practices
Manage API rate limits by following these crucial guidelines for success. Process rate limit status codes accurately, distribute request loads evenly, store results, and repeat requests strategically to boost app performance and prevent outages.
Handle Rate Limit Status Codes
As of January 2022, BigCommerce header field names are case-insensitive. Learn more about BigCommerce response header conventions.
API rate limits regulate the amount of calls being made to your app. When the quota limit is met, you can use the API's response HTTP headers to find more information about your current rate limit status:
X-Rate-Limit-Time-Window-Ms: 30000
X-Rate-Limit-Time-Reset-Ms: 15000
X-Rate-Limit-Requests-Quota: 150
X-Rate-Limit-Requests-Left: 35
Name | Description |
X-Rate-Limit-Time-Window-Ms | Shows the size of your current rate limiting window. In this case, it’s 5000 milliseconds. |
X-Rate-Limit-Time-Reset-Ms | Shows the size of your current rate limiting window. In this case, it’s 5000 milliseconds. |
X-Rate-Limit-Requests-Quota | Shows how many API requests are allowed in the current window for your client. In this case, 25 requests. |
X-Rate-Limit-Requests-Left | Details how many remaining requests your client can make in the current window before being rate limited. |
Not seeing an HTTP header in your response? Continue reading on to the next section.
Seeing a 429 Response?
If you encounter a 429 response without an API HTTP header, this is an indication of the platform undergoing a load balance to prevent any downtime from happening.
Here's an example of what a 429 response looks like:
http
Copy code
HTTP/1.1 429 Too Many Requests
Date: Mon, 03 Feb 2022 20:36:00 GMT
Content-Type: application/json
Continue to reduce the risk of an app outage by slowing down the amount of calls being made. This will reduce any strain on performance. For more details on response headers, see About Our API.
Distribute the Load
To avoid spikes in API requests and ensure efficient use of your quota, spread out your API calls over time. This practice helps prevent hitting rate limits by balancing the number of requests sent in a given time frame.
You can use strategies such as asynchronous processes, batching requests, and using a queue. These will help you distribute the load evenly. You can also keep a smooth request rate by adjusting the rate based on the API response headers.
Caching Results
Cache frequent results to reduce API calls.
Retry Requests Responsibly
To retry requests responsibly when using the BigCommerce API, follow these steps:
Monitor for 429 Responses: When you receive a 429: Too Many Requests response, it indicates that you've hit the rate limit.
Check the Retry-After Header: Use the X-Rate-Limit-Time-Reset-Ms header to determine how long to wait before retrying. This header provides the time in milliseconds until your quota resets.
Pause Before Retrying: Implement a delay in your code based on the X-Rate-Limit-Time-Reset-Ms value.
By following these steps, you can ensure your requests are retried responsibly on the BigCommerce platform.
What’s next?
Below are some helpful resources to help you ensure you’re handling your API calls correctly.
Resources:
API Rate Limits - BigCommerce Developer Documentation
Platform limits - Store limits (BigCommerce Knowledge Base)
BigCommerce: Incorporated terms - API terms (BigCommerce terms of service)
If you have questions, feedback, or issues implementing, please reach out to our DevRel team.