Rate limits
BetaThree separate budgets, the headers that report them, and what a 429 tells you.
Limits are per key, and reads, writes and purchases draw on separate budgets. That split is deliberate: a polling loop cannot exhaust the allowance for the purchases that pay for it.
Each budget is a token bucket: it holds a burst, and refills at a steady rate.
| Budget | What draws on it | Burst | Refill |
|---|---|---|---|
| Reads | Every GET | 20 | 10 per second |
| Writes | A POST that does not buy — cancelling, reporting no code, rejecting a number | 5 | 2 per second |
| Purchases | Buying an activation, renting, extending a rental | 10 | 1 per second |
These are the standard tier's figures; the Developers page shows the ones your account is on. Every response says where you stand:
RateLimit-Limit: 20
RateLimit-Remaining: 17
RateLimit-Reset: 2
RateLimit-Limit is the burst, and RateLimit-Reset is seconds until the
bucket is full again. The numbers are for the budget the request drew on, not a
single global one.
When you go over
429, with the wait in a header and in the body:
Retry-After: 3
{
"code": "rate_limited",
"status": 429,
"retry_after_seconds": 3,
"request_id": "req_8f3a2c"
}
Honour Retry-After. A client that ignores it and keeps hammering is the case
the edge is there for: requests to /v1 are also limited per key at the CDN, at
a ceiling well above any key's own budget, and that one blocks rather than
answers.
Tiers
Every account starts on the standard tier. If your integration genuinely needs more — and can say why — ask, and the account can be moved to the elevated tier without any change on your side.
The daily ceiling
Separate from rate limits, and about money rather than requests: purchases made
through the API share a daily spend ceiling, $200 unless your account has
been given another. A purchase that would cross it is refused with 403 and
daily_spend_limit_reached, and the ceiling resets at 00:00 UTC. It is visible
on the Developers page, and support can raise it.