Skip to main content
Rate limits are enforced per-token. Every response carries headers telling you the current ceiling, how much of it remains, and when the counter resets. Reading those headers is the most reliable way to stay under the limit. By the end of this page you will know what the headers carry, what a 429 looks like, and how to back off when you hit one.

​
Response headers

Exact numeric limits are not published. If your integration needs a higher ceiling, contact support with traffic estimates.

​
When you hit the limit

The API returns 429 Too Many Requests with a Retry-After header carrying the wait in seconds: 
{
  "error": {
    "code":    "rate_limited",
    "message": "Rate limit exceeded for this token",
    "details": {
      "retry_after_seconds": 14
    }
  }
}
The Retry-After value is set as both the response header and details.retry_after_seconds. They will match.

​
Limit categories

Not every endpoint counts against the same bucket. The platform splits traffic across a small number of categories so a chatty log tail does not steal capacity from a publish, and a high-volume capability call does not throttle out a token rotation. Categories share the same response headers — the X-RateLimit-* values you see reflect the bucket the current request was checked against. A token is held to the lowest remaining ceiling across whichever bucket the current request touches. There is no aggregate “total requests per minute” — each bucket is independent.

​
How to back off

​
Next

Idempotency

Make write retries safe even when the response was already produced.