To protect the stability of the API and keep it available to all users, Asana enforces multiple kinds of rate limiting. Requests that hit any of our rate limits will receive a
429 Too Many Requests response, which contains the standard
Retry-After header indicating how many seconds the client should wait before retrying the request.
The client libraries respect the rate-limited responses and will wait the appropriate amount of time before automatically retrying the request, up to a configurable maximum number of retries.
Standard Rate Limits
Our standard rate limiter imposes a quota on how many requests can be made in a given window of time. Our limits are based on minute-long windows, and differ depending on whether the domain is premium or not. We may change these quotas or add new quotas (such as maximum requests per hour) in the future.
|Domain type||Maximum requests per minute|
Although the quota is defined per minute, it is evaluated more frequently than once per minute, so you may not need to wait for a full minute before retrying your request. For requests rejected by this limiter, the
Retry-After header has the result of this calculation.
Requests rejected by this limiter still count against the quotas so that ignoring the
Retry-After header will result in fewer and fewer requests being accepted during the subsequent tine windows.
Concurrent Request Limits
In addition to limiting the total number of requests in a given time window, we also limit the number of requests being handled at any given instant. We may change these limits or add new limits in the future.
|Request type||Maximum concurrent requests|
For example, if you have 50 read requests in-flight and attempt to make another read request, the API will return a
429 Too Many Requests error. The read and write limits are independent of each other, so the number of read requests you make at one time will have no impact on the number of write requests you can make.
Responses for requests rejected by this concurrent request limiter will contain a
Retry-After header specifying a duration long enough such that the other in-flight requests are guaranteed to have either completed or timed out.