What this error means
RATE_LIMITED is returned with HTTP status 429 when your integration sends
more requests per window than the current rate limit allows. The request is
rejected before any work is done; nothing is sent and no credits are deducted.
The response also carries a Retry-After header holding the same number of
seconds as the body.
Every response for this error carries this page’s address in meta.docs_url:
Cause
The limit is shared per API key, so anything that concentrates traffic on one key trips it. The most common causes are:How to fix it
- Honor
retry_afterfirst. The envelope’sretry_afterfield (mirrored in theRetry-Afterheader) is the number of seconds to wait before reissuing the request. Sleep for that long instead of retrying immediately; an immediate retry lands in the same window and is rejected again. - Fall back to exponential backoff when the field is absent. Other transient errors do not always carry a wait time; start at one second, double on each attempt, and add jitter so concurrent clients do not re-synchronize into a new burst.
- Queue and pace batch work. Spread a bulk send over the window instead of firing it all at once; a steady drip stays under the limit where a burst does not.
- Use one key per integration. Separate keys keep separate workloads from consuming each other’s quota, and make it obvious which integration is the loud one.
Related
- Error Code Reference —
RATE_LIMITEDsits in the transient retry class: honor the returned wait time, otherwise back off exponentially. - Rate limits and cool-downs — the full runbook for limits, headers, and cool-down behavior.
- Error Handling Examples — response-envelope handling patterns in code.