Loading page
About this tool
Design consistent rate limit headers and a 429 response — IETF RateLimit draft or legacy X-RateLimit style with an RFC 9457 body.
This tool designs a complete, standards-based rate limiting contract for an HTTP API: the headers sent on every response, the 429 Too Many Requests response, and the machine-readable error body. It emits the IETF httpapi draft's structured RateLimit and RateLimit-Policy fields or the legacy X-RateLimit-* trio, a Retry-After header per RFC 9110, and an RFC 9457 application/problem+json body. API designers get a copy-paste spec that clients can actually implement backoff against.
Open API Rate Limit Header Designer on AltFTool — it loads instantly in your browser.
Paste your code or data sample into the workspace.
Pick the format, conversion, or analysis you need.
Copy the polished result straight back into your project.
429 from RFC 6585, Retry-After from RFC 9110, problem body from RFC 9457, RateLimit fields from the IETF httpapi draft.
Generates the structured RateLimit/RateLimit-Policy fields, the legacy X-RateLimit trio, or both for migrations.
Validates that remaining never exceeds the limit and reset never exceeds the window, so examples cannot contradict the policy.
The current IETF httpapi draft defines two: RateLimit-Policy (the quota rule, e.g. "default";q=100;w=60 for 100 requests per 60 seconds) and RateLimit (live state, e.g. "default";r=37;t=25 for 37 remaining and reset in 25 seconds). The older de-facto convention is X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset, which many APIs like GitHub's still use.
On every response. If clients only learn their remaining quota when they are already blocked, they cannot pace themselves; sending limit, remaining and reset on 200s lets well-behaved clients throttle proactively, and the 429 then only adds Retry-After.
Both conventions exist, which is exactly why it must be documented: GitHub sends a Unix epoch timestamp, while Twitter's original API and many gateways send delta-seconds until the window resets. The IETF draft avoids the ambiguity by defining t as seconds until reset, and Retry-After (RFC 9110) is defined as either an HTTP-date or delta-seconds.
RFC 9457 problem details JSON served as application/problem+json: a type URI pointing at your rate limit documentation, title "Too Many Requests", status 429, and a detail sentence stating the limit and when to retry. That gives SDKs one parseable error shape instead of scraping human-readable messages.