Skip to main content
The Attio API applies rate limits to all API calls to ensure fair usage and maintain the availability and stability of the platform. Our rate limit across the whole API is 100 requests per second for read requests, 25 requests per second for write requests. We may occasionally reduce the rate limit as part of incident response to protect our other systems, and we may also permanently lower it for specific APIs which handle a lot of data (this will be documented on the endpoint if so). This means that your software should be prepared to receive this response, and handle it appropriately, even if you don’t currently anticipate making this many requests.

​
Rate limit response

If you exceed the limit, you’ll get a special HTTP response, like this:
HTTP
HTTP/1.1 429 Too Many Requests
Retry-After: Tue, 23 May 2023 14:42:01 GMT
Content-Type: application/json

{
  "status_code": 429,
  "type": "rate_limit_error",
  "code": "rate_limit_exceeded",
  "message": "Rate limit exceeded, please try again later"
}
Rate limit responses always have the HTTP status code 429. They also always include a Retry-After header, which is a date at which the limit resets (usually the following second), and they may also include additional debugging information in the JSON body.

​
Handling rate limit responses

A rate limited response means that we have not processed the request, so it can be safely retried after the limit has reset. Typically this will be in the next clock second. Most programming languages offer a sleep command or equivalent that allows waiting for the reset time to elapse. Alternatively, you might want to put the request into a background queue to be processed in a different execution thread later.

​
Score-based rate limits

Attio’s List records and List entries endpoints also utilize score-based rate limits. Each request receives a complexity score. The score is a function of the requests’ sorts and filters as well as the total record/entry count for the object/list. Scores may trigger rate limits in two ways:
  1. The score for an individual query may exceed the per-query limit. In this case, you should reduce the complexity of your query and try again.
  2. The summed scores across multiple queries may exceed the limit for a given window of time. For this limit, we utilize a sliding window algorithm with a 10 second window. Scores are summed across all apps and access tokens using the API. You will receive a clear 429 error and a Retry-After header when you hit a limit.