Bitcall APIRate Limits
How request quotas are counted and what to do when you hit one.
The gateway enforces a fixed-window rate limit on every authenticated request. Exceeding it returns 429:
{
"error": {
"code": "RATE_LIMITED",
"message": "Too many requests. Retry after the interval in `Retry-After`.",
"requestId": "9f1c7b2e-4a83-4d21-9c55-1f0b3a7e2d64"
}
}The response carries a Retry-After header giving the number of seconds to wait. Read it rather than guessing — it is the authoritative answer.
Counted per user, not per key
Quota belongs to the user, and every key that user holds draws from the same bucket.
Issuing more keys does not increase throughput. If you need more, ask for a higher limit — more credentials will not give you one.
Within each window a counter increments per request. Once it passes the limit, further requests are rejected until the window rolls over. The default window is 60 seconds.
Handling a 429
- Wait for
Retry-After, then retry. The value is in seconds. - Spread load rather than bursting. A fixed window forgives steady traffic far better than spikes — the same total volume sent evenly may never hit the limit at all.
- Back off on repeats. If you are being limited continuously, add exponential backoff so retries do not become the load.
- If you consistently need more headroom, ask whoever issued your key to raise your limit.
Rate limiting protects capacity, not authorization. If the counter store is briefly unavailable the gateway fails open and allows the request rather than blocking traffic — so never treat a limit as a security control.