Rate Limits

Rate limiting applies to API-key traffic and is counted per key. The counter is shared across every server instance, so the limit is the same limit no matter which one answers your request. Browser sessions (JWT) are not rate limited.

The Limit

ScopeLimitWindow
Per API key600 requests / minuteFixed 60-second window

One limit, every endpoint — there is no separate quota for reports or file uploads. The window is fixed, not sliding: it opens on your first request and resets 60 seconds later, whatever happened in between. The ceiling is deliberately generous — a full re-scan of a large company at 200 rows a page stays far below it — so it acts as backpressure against a runaway client rather than as a quota. If a migration or a bulk import genuinely needs more, ask support to raise the limit for your key.

Rate Limit Headers

Every response to an API-key request carries the current state of your window:

X-RateLimit-Limit: 600
X-RateLimit-Remaining: 587
X-RateLimit-Reset: 1774428060
HeaderMeaning
X-RateLimit-LimitRequests allowed in one window for this key.
X-RateLimit-RemainingRequests left in the current window. Never negative.
X-RateLimit-ResetUnix timestamp in seconds at which the window resets and the counter returns to zero.

When Rate Limited

Going over the limit returns 429 Too Many Requests with a Retry-After header, in seconds. The same number is repeated in the body as retryAfter.

Cap the wait at 60 seconds. The window is a minute long, so a correct Retry-After is never larger than that — but the current release can compute it against a clock in a different timezone to the one the window was written in, and hand back a value hours long. Treat the header as min(Retry-After, 60) and a client that honours it will never stall for the rest of the morning over a sixty-second window.
HTTP/1.1 429 Too Many Requests
Retry-After: 37
X-RateLimit-Limit: 600
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1774428060
{
  "success": false,
  "error": {
    "status": 429,
    "code": "RATE_LIMITED",
    "message": "חריגה ממגבלת הקצב (600 בקשות לדקה). יש לנסות שוב בעוד 37 שניות.",
    "retryAfter": 37
  }
}
Best practice: honour Retry-After rather than guessing. Because the window is fixed, sleeping until X-RateLimit-Reset clears the whole backlog at once; blind exponential backoff just spends more of the next window on retries.
Retrying a write? Send an Idempotency-Key with document creation so a retry after a 429 or a timeout can never issue a second document. See Idempotency.

Last updated