Skip to main content
Rate limits protect the platform from bursts. They are not how spending is controlled; credits do that.

The limits

10 requests per second, with a burst of 20. The bucket is per API key, so one key’s traffic cannot exhaust another’s.

The headers

Every response carries:
There is no X-RateLimit-Reset. The bucket refills continuously rather than at a fixed boundary, so there is no instant to report.

When you exceed it

429, with a Retry-After header in seconds. A rate-limited request is never charged: it did no work. Back off and retry. Retry-After is the honest answer; exponential backoff on top of it is polite.

What is not rate limited

Provider-backed work (placing calls, running agents) is governed by your credit balance, not by request count. A rate limit is about protecting shared infrastructure; a balance is about what you have paid for. Conflating the two would mean a well-funded customer being throttled for spending money. Concurrent calls are capped separately, per account, and default to 5, raised on request. Web and app sessions count toward the same limit, and a call placed while the account is at it is refused with 503. A campaign dials its leads back to back and does not wait for a free slot, so a lead it reaches while the account is at the limit is recorded as a failed call. Starting a campaign again after it has stopped or completed dials every lead again.