> ## Documentation Index
> Fetch the complete documentation index at: https://docs.brightalk.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Rate limits

> Understand rate-limit responses for read, write, and execution requests.

If Brightalk returns `429 rate_limit_exceeded`, your integration sent more requests than the current allowance for that type of operation. The response tells you how long to wait.

## Wait, then retry safely

1. Read the latest `Retry-After` from each `429` response.
2. Wait at least that interval, then add a small random delay. On subsequent `429` responses, honor the newest `Retry-After` and increase the randomized delay up to a caller-defined cap to avoid a tight, unbounded retry loop.
3. Retry only when the operation is safe and within a caller-defined maximum-attempt count or elapsed-time/deadline budget. Stop and surface the error when that budget is exhausted. For the same logical write, within the [documented idempotency boundary](/en/idempotency), preserve the same HTTP method, path, API version, semantically identical body, and original `Idempotency-Key`.

Coordinate worker processes that share one organization's allowance instead of letting them retry independently.

Do not hard-code one global request limit. Brightalk applies limits per organization and may apply a lower limit to an individual key; the response headers are authoritative for the current request.

## Three independent counters

Operations consume one of three independent buckets:

| Bucket      | Operation examples                                                                      |
| ----------- | --------------------------------------------------------------------------------------- |
| `read`      | List and retrieve resources                                                             |
| `write`     | Contact writes; create batch; cancel call; pause or cancel batch; cancel Automation run |
| `execution` | Create call; start or resume batch; create Automation run                               |

Cancellation and pause operations consume `write`, not `execution`. Telephony work initiated by an accepted execution request does not consume another HTTP request allowance.

## Read the response headers

| Header                | Meaning                                                                                          |
| --------------------- | ------------------------------------------------------------------------------------------------ |
| `RateLimit-Limit`     | Effective allowance for the selected bucket                                                      |
| `RateLimit-Remaining` | Nonnegative requests remaining in that bucket                                                    |
| `RateLimit-Reset`     | Nonnegative integer delta-seconds from response generation until reset; never an epoch timestamp |
| `Retry-After`         | Nonnegative integer delta-seconds to wait before retrying a denied request                       |

Use these values instead of assuming that every organization or key has the same allowance.

## Queued is not rate-limited

Telephony concurrency is a different control. When capacity is temporarily full, already accepted work remains `queued`; it does not become a `429` and is not dropped. Poll the API resource and treat queueing as lifecycle state, not a request-throttling signal.