Rate limits
Each key can make 120 requests a minute, and up to 30 of them can be sends. The limit is there to stop a runaway loop, not to meter you.
Where you stand
Every response says how much of the minute is left:
Headers
X-RateLimit-Limit: 120
X-RateLimit-Remaining: 119
X-RateLimit-Reset: 1790499600X-RateLimit-Reset is when the minute ends, in Unix seconds. A request counts before its permission is checked, so a refused one uses up the minute too.
When you’re over
You get 429 rate_limited, with Retry-After in seconds. Wait that long before the next request.
Response
HTTP/1.1 429 Too Many Requests
Retry-After: 21
{
"error": {
"code": "rate_limited",
"message": "Too many requests. Try again in 21s."
}
}Sends
Sending a draft counts against a narrower allowance of 30 a minute as well as the 120, so an integration that polls hard can’t use up its own ability to send.
Staying inside it
The counters live in the memory of each of our servers, so the limit is approximate: behind several servers you may get more than 120 before a refusal, and a deploy starts the minute again.
Change a screenful of conversations with one call to Update many threads, not one each.
Ask List imports for folders once, not on every poll.
When polling for new mail, a minute between polls is plenty: DMU Mail checks each mailbox every few minutes.