Rate Limiting

What is Rate Limiting?

Every API of consequence enforces limits, usually expressed as requests per second, per minute or per day, and often scoped per key, per tenant or per endpoint. Exceeding them returns an HTTP 429 rather than the data you wanted. Handling that well is the difference between an integration that degrades gracefully and one that loses records silently. The correct pattern is to read the rate-limit headers the API returns, back off exponentially with jitter when throttled, queue rather than drop, and treat a 429 as a retryable condition distinct from a real error. In go-to-market stacks rate limits are a live constraint rather than a theoretical one, because enrichment providers, CRMs and mail APIs all impose them, and a bulk operation that ignores them will either be throttled to a crawl or fail halfway through. The related discipline on the sending side is throttling, where you cap your own outbound volume deliberately.

Why it matters

• A 429 handled badly loses data quietly, which is far worse than a visible failure.
• Exponential backoff with jitter prevents a retry storm from making the throttling worse.
• Limits shape architecture — bulk operations must be designed around them, not retrofitted.

Use cases

• Bulk enrichment. A large job paced to stay inside the provider's per-minute ceiling.
• Backoff handling. 429 responses retried with increasing delay rather than dropped.
• Per-key quotas. Separate keys per integration so one consumer cannot exhaust another's quota.