RaabtaHQ
Rate limits

Rate limits

Per-key request budgets, per-key overrides, the separate budget for failed authentication, the X-RateLimit headers and how to back off on a 429.

The per-key budget

Each key may make 60 requests per 60 seconds by default. The number is set per business, so yours may be higher — GET /me reports the limit the key you are holding is actually subject to, and every response carries it in X-RateLimit-Limit. Read one of those rather than assuming this figure.

The window is fixed, not sliding: it starts on the minute and the budget refills all at once, which is what X-RateLimit-Reset tells you. Counting happens in the database, so the limit holds across every server that handles your traffic — there is no fresh budget to be had by reconnecting.

Most calls cost one unit. A few cost more because they do more work on the account's behalf:

Per-key overrides

The business's limit is a ceiling, not an allowance to share: every key gets the full number, counted separately. An admin can give one key a lowerlimit when creating or editing it, so a low-trust integration cannot exhaust the account's capacity on its own. A key can never be given more than its business has.

GET /me reports the limit a key is actually subject to as rate_limit_per_minute. If the business limit is lowered below a key's own number, the lower one applies from the next request; nothing needs re-issuing.

Failed authentication

Requests that present no usable key are counted separately, per client address, at 30 per minute. Past that, every request from the address returns 429 rate_limited until the window passes, whether or not the key it carries is valid. This makes guessing keys pointless without inconveniencing a client whose key was just rotated.

A deploy that ships an old key will trip this budget in seconds. If every call is suddenly a 429 with the message Too many failed authentication attempts, the problem is the key, not the limit.

Headers

Every response — success or failure — carries the state of the key's window after that request was counted:

HeaderMeaning
X-RateLimit-LimitThe key's budget per window.
X-RateLimit-RemainingUnits left in the current window. Never below zero.
X-RateLimit-ResetWhen the window resets, as Unix seconds.
Retry-AfterOnly on a 429: seconds to wait before retrying. Honour it rather than computing your own backoff from the reset time.

Handling a 429

429 Too Many Requests
HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1788000060
Retry-After: 12
Content-Type: application/json

{
  "error": {
    "code": "rate_limited",
    "message": "Rate limit exceeded for this API key",
    "request_id": "req_01J9X4S2A9QD1H6E"
  }
}

Wait Retry-After seconds, then retry the same request. A POST retried with the same Idempotency-Key is safe: a 429 is never stored as an idempotent result, so the retry executes for real — see Idempotency. For sustained throughput, watch X-RateLimit-Remaining and slow down before it reaches zero instead of reacting to the 429.