429: Explain a rate limit
02A response explains that the user sent too many requests; an optional Retry-After field can suggest a waiting period.
This response chooses to include a 30-second delay. A later request still has to pass the server’s policy checks.
Source for this drawing: RFC 6585 · Read RFC section 4 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- Rate limit
- A policy controlling how many requests are accepted over time.
- Retry-After
- An optional response field describing when a follow-up request should be attempted.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A rate limit is a server policy, not a universal request quota.
- 429 Too Many Requests indicates that the user sent too many requests in a given amount of time. The response representation SHOULD explain the condition and MAY include Retry-After.
- RFC 6585 does not define how to identify users, count requests, or choose a quota. A per-account policy of two requests per interval is only the drawing’s example.
- 429 responses MUST NOT be stored by a cache. Under attack or heavy load, servers are not required to send 429 for every rejected request and may instead drop connections or take other steps.
Retry-After: 30 is an illustrative delay in seconds; HTTP also permits an HTTP-date (RFC 9110 §10.2.3). Waiting does not guarantee that a retry will succeed. The drawing does not assert that 429 must carry Retry-After or that rate limits prevent attacks.
Read the RFC section ↗