Rate limits

Requests are limited per API key, not per IP address. Two integrations behind the same NAT do not compete for the same budget, and one runaway script cannot exhaust everyone else's.

The default is 120 requests per minute per key. You can raise or lower it per key when you create it, which is useful for giving a batch job a larger budget than an interactive service.

When you exceed it

You get 429 with a rate_limit_error:

json

{
  "error": {
    "type": "rate_limit_error",
    "code": "RATE_LIMIT_EXCEEDED",
    "message": "Too many requests"
  },
  "request_id": "req_a1b2c3d4"
}

Responses carry the usual headers so you can stay ahead of the limit rather than discovering it:

Header	Meaning
`x-ratelimit-limit`	Requests allowed in the window
`x-ratelimit-remaining`	Requests left in the current window
`x-ratelimit-reset`	Seconds until the window resets
`retry-after`	Sent with `429` — seconds to wait

Staying within the limit

Do not poll tightly. Polling a call's status every second burns 60 requests a minute to learn something that changes every few minutes. Poll every 5–10 seconds, and back off once a call is completed and you are only waiting on the report.

Place bulk calls with a campaign, not a loop. A campaign takes the whole recipient list in one import and paces the calls itself, respecting your organization's concurrent-call limit. A for loop over POST /v1/calls does neither.