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.

​
Three independent counters

Operations consume one of three independent buckets: 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

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.