rate-limit-handlinglisted

# Rate limit handling Rate limits are a contract, and hitting them repeatedly can escalate from throttling to suspension. Handling them well means staying under proactively rather than reacting to rejections. ## Method 1. **Read the limit headers, not just the errors.** Providers report remaining quota and reset time, which allows slowing down before being rejected. 2. **Honour the retry-after value.** It is the provider telling you exactly when to return, and ignoring it is what turns throttling into a block. 3. **Throttle client-side to stay under.** A token bucket sized below the limit prevents most rejections entirely (see rate-limiting). 4. **Back off exponentially with jitter.** Synchronised retries from many workers reproduce the burst that caused the limit (see timeouts-and-retries). 5. **Queue rather than drop where the work matters.** Deferring work to stay within quota is usually better than failing it, provided the queue is bounded. 6. **Batch where the API supports it.** One request for fifty records uses one unit of quota rather than fifty, which is often the whole solution. 7. **Monitor quota consumption as a metric.** Approaching the limit is a capacity signal that needs action before it becomes errors (see alerting-design). ## Boundaries Limits vary by endpoint, plan, and time, and are sometimes undocumented. Client-side throttling requires coordination across instances to be accurate. Persistent limit pressure is a