Skip to content

Rate limits

The gateway enforces rate limits at the organization level and, optionally, at the user level. Limits are configured by your admins; this guide covers how to read and respond to them as an API client.

Every response carries the current limit state:

Header Type Description
X-RateLimit-Limit integer Maximum requests permitted in the current window.
X-RateLimit-Remaining integer Requests remaining in the current window.
X-RateLimit-Reset integer Unix timestamp (seconds) when the current window resets.

Read X-RateLimit-Remaining proactively — when it approaches zero, slow down before you are throttled.

Exceeding the limit returns 429 with a Retry-After header alongside the rate-limit headers:

HTTP/1.1 429 Too Many Requests
Retry-After: 12
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1741442333
{ "error": { "code": "quota_exceeded", "message": "Rate limit exceeded." } }

The same quota_exceeded code is also returned when a configured token budget (not just request count) is exhausted.

Note the two timing headers use different units:

  • Retry-After is a relative count of seconds to wait from now (the example above says wait 12 seconds).
  • X-RateLimit-Reset is an absolute Unix timestamp (seconds) at which the window refills.

They describe the same moment; pick whichever your client handles more naturally.

On 429:

  1. Honor Retry-After — wait that many seconds before retrying. (Equivalently, wait until the X-RateLimit-Reset timestamp.) That is the precise moment capacity frees up.
  2. If no Retry-After is present, use exponential backoff with jitter (start ~1s, double per attempt, cap ~30s).
  3. Do not hammer the endpoint — repeated immediate retries extend the throttling window for your whole organization.

For sustained high throughput, ask your admins to raise the org limit or distribute load across time rather than retrying aggressively.