Rate limits

Every API token gets its own sliding-window budget of 1000 requests per minute. The window is per-token, not per-tenant — issuing a second token doubles your headroom, no support ticket required.

On exceed

Requests past the budget get a 429 with code: rate_limit_exceeded in the error envelope and a Retry-After header naming the number of seconds until the window opens again. Honor the header — retrying sooner just consumes more of next minute's budget.

Burst posture

The 1000/min budget is throughput, not burst — a token may spend its full budget in the first 100ms of a minute and then sit blocked for the remaining 59.9s. This is intentional. The limit protects shared compute, not individual round-trip latency, so consolidating traffic into early-second bursts is allowed.

Per-token isolation

Different tokens have independent budgets, even within the same tenant. A CI token hitting /v1/services cannot starve a dashboard token reading /v1/incidents. The recommended pattern is one token per integration so a misbehaving script is self-throttling rather than tenant-throttling.

When to ask for more

If 1000/min becomes a real ceiling for a legitimate use case, contact support — manual lifts are a same-business-day process. The limit was chosen as a default, not as a wall.

See also: Errors for the envelope shape and Idempotency for retry-safe writes.