Skip to main content

Rate Limiting

How rate limiting works​

The API enforces rate limits using a fixed 60-second window for your organization. Each window admits up to {N} requests; when the window ends, the counter resets and a new window begins with the full quota. Nothing carries over between windows — unused capacity is not banked, and requests in one window don't count against the next.

Two properties of the window matter when designing your retry logic:

  • The window is fixed, not rolling. Window boundaries are fixed points in time, independent of when you send your first request. If your first request arrives 40 seconds into the current window, the quota resets about 20 seconds later — not 60 seconds after your request.
  • Boundaries don't align to clock minutes. The reset does not necessarily happen at :00 seconds. Some endpoints report the time until reset in their 429 response headers; see Rate limit headers.

Rate limit responses​

When you exceed the limit, the API returns HTTP 429 with a plain-text body:

API rate limited

Some endpoints also return rate limit headers with the 429 response. See Rate limit headers.

Because windows are fixed at 60 seconds, a 429 response guarantees the current window ends within at most 60 seconds. That leads to a simple, reliable strategy:

  1. On 429, wait 60 seconds (plus a small random jitter), then retry. This always lands your retry in a fresh window. Waiting less risks retrying inside the same, still-exhausted window. If the response includes a Retry-After header, wait that number of seconds instead.

  2. Don't retry in a tight loop. Requests rejected during the current window don't extend the window or reduce the next window's quota — but they gain you nothing. Every retry before the reset is a wasted call.

  3. Resume at your normal rate after backing off. Don't flush a queued backlog all at once when the new window starts, or you'll exhaust the fresh quota immediately and be rate limited again.

Requests near the window boundary​

The rate limit check happens once, when a request is admitted. A request admitted near the end of a window (for example, at second 59) runs to completion and returns a normal response, even if processing crosses into the next window. It counts against the window in which it arrived.