RateLimit headers (IETF)
The IETF RateLimit header draft (draft-ietf-httpapi-ratelimit-headers) standardises how HTTP APIs communicate quota information to clients using three headers: RateLimit-Limit (the request quota), RateLimit-Remaining (requests left in the current window), and RateLimit-Reset (seconds until the window resets — relative, not a unix timestamp). The draft is a work-in-progress replacement for the legacy X-RateLimit-* header family used by most APIs today.
Formula
Key difference from legacy headers: RateLimit-Reset in IETF draft = seconds until reset (relative). X-RateLimit-Reset in legacy = unix epoch timestamp (absolute). Clients that parse one format as the other will compute wildly incorrect retry timings.Why it matters in practice
Standardised headers allow generic HTTP clients and middleware to implement rate limit handling automatically, without API-specific logic. Clients can read RateLimit-Remaining to proactively slow down before hitting the limit, rather than waiting for a 429. The RateLimit-Policy header (also in the draft) allows programmatic discovery of the rate limit policy, enabling adaptive clients.
Common mistakes
- •Mixing IETF draft headers and legacy X-RateLimit-* headers in the same response — clients that support both may misinterpret the combined signal.
- •Not documenting which header format your API uses — the parsing difference for Reset (relative vs absolute) causes client bugs that are hard to diagnose.
- •Setting RateLimit-Reset as an absolute timestamp instead of relative seconds — this violates the IETF draft specification.