Rate limits

Request limits for the Management API and how to handle 429 responses.

The Management API is not billable, but it is limited — per token, separately from inference traffic. A busy CI pipeline cannot throttle your production inference, and inference load cannot starve your automation.

Default limits

Each token has a token bucket: it holds up to 100 requests (the burst) and refills continuously at 600 requests per minute (10 per second). Every request spends one. A full bucket lets you send 100 requests at once; after that you can sustain 600 per minute.

Limit	Default
Sustained rate (refill)	600 requests per minute, per token
Burst (bucket size)	100 requests

Note

These numbers are defaults and may change (typically upward). Do not hard-code them — read the response headers instead. Treat them as the rate you can rely on, not as an exact ceiling.

Response headers

Every authenticated Management API response carries the bucket state — success, 4xx from the API and 429 alike. A request rejected before the token is verified (401, or a 500 while verifying it) is not counted and carries none of these headers. Do not treat a missing X-RateLimit-* header as an error; read them when present.

Header	Meaning
`X-RateLimit-Limit`	The sustained rate for this token, in requests per minute (the refill rate, e.g. `600`). It is not the number of requests you can send right now.
`X-RateLimit-Remaining`	Whole requests left in the bucket after this one. Never more than the burst (`100`), however high `X-RateLimit-Limit` is.
`X-RateLimit-Reset`	When the bucket will be full again (back to the burst) if you send nothing more, as a Unix timestamp in seconds. It is not a window boundary: requests become available again continuously before then.

When you hit the limit

The request is rejected with 429 and a Retry-After header (seconds until the bucket holds one request again). No change was made.

HTTP/1.1 429 Too Many Requests
Retry-After: 1
X-RateLimit-Limit: 600
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1790236810
X-Request-Id: req_6f1c2d9e8a4b4c3d9e2f1a2b3c4d5e6f

{
  "error": {
    "message": "rate limit exceeded for this token; retry after 1 s",
    "type": "rate_limit_error",
    "code": "rate_limit_exceeded",
    "param": null,
    "action": "Wait Retry-After seconds, then retry.",
    "request_id": "req_6f1c2d9e8a4b4c3d9e2f1a2b3c4d5e6f"
  }
}

Wait Retry-After seconds, then retry. For a write, retry with the same Idempotency-Key — see Idempotency.

Tip

Applying many changes in one go? Pace your writes from X-RateLimit-Remaining rather than sending everything and backing off. Using separate tokens per pipeline also gives each its own budget — and a clearer audit trail.

Inference rate limits are separate and documented in Rate limits.