Skip to main content
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, 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.

​
Five independent counters

Operations consume one of five independent buckets: Cancellation and pause operations consume write, not execution. Transcript polling and recording polling each use their own dedicated bucket instead of consuming the general read allowance. Telephony work initiated by an accepted execution request does not consume another HTTP request allowance.

​
Recording downloads are not rate-limited — issuance is

GET /recordings and GET /recordings/{recording_id} consume the recording bucket like any other request, but fetching the signed download_url they return does not. That URL is served from a different host with no API key and no bucket to charge against. Throttling happens where the URL is minted, not where it is used: the number of valid download URLs that can exist at any moment is bounded by how many recording-bucket requests you are allowed per minute times the TTL window each one is minted with, not by a separate limit on the download itself.

​
Read the response headers

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.