Rate limits

Your allowance is counted per credential owner and per operation — per team for an API key, per OAuth client for the client-credentials flow — in fixed 60-second windows: 3000 requests per minute on submit and synchronous operations (policy submit) and 6000 per minute on poll operations (policy poll). Each operation publishes the policy that governs it in x-rate-limit, and every response the API renders names the one that applied in RateLimit-Policy.

Every response the API renders — success and error alike — reports what is left. The exceptions are the two the gateway answers before the API sees the request, 401 and 403, which carry none of these headers:

• X-RateLimit-Limit — the allowance for this operation in the current window.

• X-RateLimit-Remaining — requests still available in it.

• X-RateLimit-Reset — when the window resets, as UTC epoch seconds (not a delay).

• RateLimit-Policy ("submit";q=3000;w=60) and RateLimit ("submit";r=2999;t=37) — the same figures as the structured fields of draft-ietf-httpapi-ratelimit-headers, an Internet-Draft rather than a published standard, so their syntax is provisional; the X-RateLimit-* triple carries the same figures and is not subject to that draft.

Exceeding your allowance answers 429 with an Error body (code: rate_limited), Retry-After set to the seconds left in the window, and the headers above with X-RateLimit-Remaining: 0. Nothing is charged — the request is refused before it is validated or admitted.

A second, coarser limit protects the service as a whole: a per-operation floor of 50 requests/second with a burst of 100 (100/second, burst 200 on poll operations) that every caller of that operation shares. Crossing it answers 429 with a GatewayError body and Retry-After: 1, and carries no quota headers — those requests are refused before the API sees them. Below that floor, one caller's traffic cannot consume another's allowance.

Retry-After on a 202, 503 or 504 is a poll or backoff hint and carries no quota meaning; only on a 429 does it mean "your window resets in N seconds". Honour it wherever it appears, poll at the pace it suggests rather than in a tight loop, and back off exponentially with jitter after a 429.

Published floors

Sustained rate	Burst	Applies to	Operations
50 requests/second	100	submit, synchronous	18
100 requests/second	200	poll	16

What a 429 looks like

Your allowance for this operation is exhausted:

{
  "status": "ERROR",
  "status_code": 429,
  "message": "Rate limit exceeded for this operation's allowance (submit: 3000 requests per 60 s). Retry after the interval in the Retry-After header.",
  "code": "rate_limited"
}

The per-operation floor shared by all callers was crossed:

{
  "status": "ERROR",
  "status_code": 429,
  "message": "Rate limit exceeded. Retry after the interval in the Retry-After header."
}

The first carries a machine-readable code and the quota headers; the second is the gateway's own refusal, which has neither. Back off exponentially with jitter from the Retry-After value rather than retrying on a fixed interval.

These floors are per operation and shared by every caller of it — they sit above your own allowance, which is counted per credential owner. Above a floor the gateway answers 429 itself, before the API sees the request, and sets Retry-After.

That refusal carries no quota headers: those report what is left of your allowance, not of a floor shared with everyone else. Treat the published numbers as the contract, honour Retry-After, and back off exponentially.