POST /api/chat/v1, POST /api/chat/v2, GET /api/chat/v2/stream/{runId} and
GET /api/chat/v2/quotas — is authenticated with the same x-api-key header and counts
against those limits.
There are two ways to see where you stand: response headers when a request is rejected,
and the quotas endpoint at any time.
Rate-limit headers on 429
When a request is rejected we return 429 with the standard IETF rate-limit headers:
Both
Retry-After and RateLimit-Reset are relative seconds, computed at the moment
of rejection, so you never have to reconcile a timestamp against your own clock.
If your key has several limits, these headers describe only the one limit that caused this
particular 429 — not your whole budget. Use /quotas for the full
picture.
These headers appear only on 429 responses. Successful responses (200) carry no rate-limit
headers: with multiple limits in play there is no single limit a success could unambiguously
describe, and nothing was rejected. Poll
/quotas instead of scraping headers off successful
calls.Handling a 429
RespectRetry-After rather than retrying on a fixed schedule:
Checking your quotas
GET /api/chat/v2/quotas returns every limit configured on your key, so you can throttle
before you get rejected.
Limits are fixed-window, not calendar-aligned: a window starts at a fixed multiple of
duration since the Unix epoch. A 30-day limit therefore does not reset on the 1st of the
month — always read reset rather than assuming a calendar boundary.
/quotas is authenticated like any other route and consumes 1 request from each of your
limits, exactly as an inference call would. Polling every 1–5 minutes is fine; calling it before
every request is not.Next steps
Quickstart
Make your first call to the Chat API.
Reconnecting a stream
Resume a stream after a disconnect instead of re-asking the question.
API reference
Endpoint schemas and playgrounds for every route.
Support
Email us to raise your limits.