Rate limits

120 requests per minute per key by default, reported on every response, with a 429 and a reset when the bucket empties.

The public API is rate limited per key. The default budget is 120 requests per 60 seconds, refilling continuously rather than resetting on a fixed boundary.

Headers on every response

Every response — successful or not — carries the current state of your budget, so there is no need to guess or to track it yourself.

X-RateLimit-Limitinteger

The size of the bucket. 120 unless your workspace has a negotiated override.

X-RateLimit-Remaininginteger

Requests still available right now.

X-RateLimit-Resetseconds

Seconds until the bucket has refilled.

When you exceed it

Requests over budget return 429 with a JSON body. Nothing is queued and nothing is partially applied — a rejected call was not placed.

{
  "status": 429,
  "error": "Rate limit exceeded"
}

Read X-RateLimit-Reset and wait that long. Retrying immediately on a 429 spends the next refill on retries rather than on work.

Batching beats retrying

If you are pushing a contact list, create a call job rather than looping over POST /outbound/calls. One job of ten thousand rows is one request; ten thousand individual calls is a rate limit problem you built yourself.

Raising the limit

The budget is configurable per workspace — capacity, refill amount and refill period are all separate settings, so a high-volume integration can be given a larger bucket or a faster refill rather than one blunt multiplier. Ask if the default does not fit your integration.

Concurrency is a different limit

Rate limits govern API requests. How many calls can be in progress at once is governed separately, per phone number, and exceeding it queues rather than fails. See Core concepts.