Rate limits
Default limit
Every request is subject to a baseline app-wide limit: 300 requests per minute. This applies regardless of whether you're authenticated — it's the floor that protects the service from any single caller, including unauthenticated ones hitting public endpoints.
Tighter limits on call-placing endpoints
Creating a campaign, adding targets to one, starting one, and placing a direct call are all throttled per organization, more tightly than the default, because each of these can trigger real, billed phone calls:
| Endpoint | Limit |
|---|---|
POST /api/outbound-campaigns | 20 / minute |
POST /api/outbound-campaigns/{id}/targets | 20 / minute |
POST /api/outbound-campaigns/{id}/start | 10 / minute |
POST /api/phone/call | 20 / minute |
These are tracked per organization, not per API key or per IP — if you use multiple keys for the same org, they share the same limit.
Handling 429
{
"statusCode": 429,
"message": "ThrottlerException: Too Many Requests"
}
Back off and retry — a fixed delay (a few seconds) is enough for the
window to reset. If you're running a bulk operation (loading thousands of
targets into a campaign, for instance), batch requests instead of firing
them all at once; POST /api/outbound-campaigns/{id}/targets already
accepts an array of numbers in a single call, so you rarely need more than
one request per batch of targets anyway.
Why this matters more here than on a typical read-only API
Credit deduction for calls happens after the call completes, not as a pre-flight check when you create a campaign or dial a number. That means the rate limit — not a balance check — is what actually caps how fast a compromised or buggy integration could run up usage. Keep your API key as secret as you would a database password; see Authentication.