Skip to content

Rate limits

Two independent 120-per-minute limits, one per IP and one per workspace, the stricter caps on exports, crawls and topics, and a backoff loop that behaves.

Requires API access to be enabled for your workspace

v1 enforces two rate limits. They are independent, and either can reject a request.

The per-IP limit runs first, deliberately: it bounds floods of missing or invalid keys, which would otherwise reach a database lookup unthrottled. The per-workspace limit is what bounds one valid key sprayed across many machines.

So a single client from one address is effectively capped at 120 requests per minute; five servers sharing one key are still capped at 120 per minute in total.

Stricter per-endpoint limits

A few endpoints carry their own limit on top of the global two, because each request is expensive:

All of them return the same 429 as the global limits.

The response

HTTP status 429.

Backing off

Retry with exponential backoff and jitter, and cap the number of attempts.

with-backoff.mjs

Two things to avoid:

  • Retrying immediately. The window is a minute; an instant retry just spends another request.
  • Retrying anything else. UNAUTHORIZED and FORBIDDEN will not resolve themselves. See Errors.

Staying under the limit

  • Use the maximum limit of 200 when paging, so a given dataset costs fewer requests. See Pagination.
  • Sync on a schedule rather than polling in a loop. Nothing in v1 changes fast enough to reward a tight poll.
  • For "tell me when something happens", use webhooks instead of polling — they push, and they cost you no requests.

Where to go next

Last updated