API Rate Limiting Explained: Why It Exists and How to Work With It

429 Too Many Requests is the standard status code for rate limiting, defined in RFC 6585. The response should include a Retry-After header indicating either the number of seconds to wait or a specific UTC datetime when the limit resets. Many APIs also return rate limit information in every response as headers: X-RateLimit-Limit (total requests allowed), X-RateLimit-Remaining (requests left in current window), and X-RateLimit-Reset (Unix timestamp when the window resets). Reading these headers proactively lets you slow down before hitting the limit rather than after.

Fixed window rate limiting counts requests within fixed time buckets — for example, 100 requests per minute, where the minute resets at :00 seconds on the clock. Problem: you can send 100 requests at 0:59 and 100 more at 1:01, effectively making 200 requests in two seconds. Sliding window rate limiting counts requests within a rolling time window — 100 requests in the last 60 seconds, recalculated continuously. This is fairer and prevents the burst problem but requires more memory to implement. Token bucket and leaky bucket are algorithm variants that smooth out burst traffic more elegantly.

The standard pattern is exponential backoff with jitter. When you receive a 429, wait a short period and retry. If you get another 429, wait twice as long. Repeat up to a maximum number of attempts. Add random jitter (a small random delay) to prevent multiple clients from synchronizing their retries and hammering the API simultaneously when the window resets. Read the Retry-After header if present and wait at least that long before retrying. Implement a circuit breaker that stops retrying after N consecutive failures and alerts your team — persistent rate limiting usually means you need to reduce request volume or upgrade your API tier.