Skip to content
All pages

Concepts

Rate limits

A ceiling on speed, not a meter on spend. What is actually sold is the plan's monthly report allowance; the per-minute limit exists so one runaway loop cannot degrade the service for everyone else.

The ceilings

Limits are per token, not per IP: several consumers behind one NAT are not one consumer, and one consumer moving between hosts is not several. Your own ceiling is stated in limits.rate_limit_per_minute on GET /api/v1, so a client can pace itself without discovering the number the hard way.

  • 120 requests a minute per token on plans that include the API.
  • 600 a minute on Enterprise, where an integration genuinely moves more.
  • 20 a minute for requests with no usable credential, deliberately tight.
  • A flood ceiling of 600 a minute per connection above all of that, generous enough that legitimate tokens sharing an egress never meet it.

When you meet one

The answer is 429 rate_limited with a Retry-After header naming the wait in seconds. Trust the header over a guess, pause the whole worker rather than the one request, and if you are near the ceiling by design, spread the load instead of bursting: batches exist so a hundred rows are one request.

Backing off, honestly
import time

def with_backoff(send, attempts=5):
    for attempt in range(attempts):
        response = send()
        if response.status_code != 429:
            return response
        # The server names the wait; trust it over a guess.
        time.sleep(int(response.headers.get("Retry-After", 2 ** attempt)))
    return response
esc
move open 72 places