Rate limits

We have rate limits in place in order to provide a fair response time to all our API users.

The primary rate limit is 40 requests per second. All requests count towards the rate limit.

If the rate limit is exceeded, the API returns a 429 status code indicating Too Many Requests,

with the error message Your request rate has exceeded our rate limit..

Exponential backoff. ChartMogul libraries support exponential backoff to reactively manage rate limits. Learn how our Ruby, Node, PHP, Go and Python clients handle exponential backoff.

Additional limits

To provide a reliable experience to all our API users, we have introduced another layer of rate limits.

In addition to the primary limit of 40 requests per second, we also limit:

The compute time consumed per minute per account. Responds with 429 Too many requests.
The number of parallel requests. Please don't exceed 20 parallel connections. Responds with 503 Service unavailable.

When these limits apply. Users using the deprecated page parameter for paging with List API endpoints may hit consumption-based rate limits. This is because the deprecated paging method has lower performance. We advise everyone to use cursor-based pagination, which results in better performance of List API endpoints and is less likely to hit consumption-based rate limits.

Other users are unlikely to notice these additional limits. They are meant to restrict only the most demanding requests so all our API users can benefit from optimal response times.

Strategies for reacting to rate limiting

If you do exceed the rate limits, try one of the following approaches:

Switch to cursor-based pagination for List API endpoints.
Limit the number of parallel requests.
For large data sets, use alternatives to API:
- Set up automatic exports using one of our Destinations.
- Export them from ChartMogul instead of using the API.

If these strategies don’t help, please contact support to discuss a remedy.