What do the X-RateLimit headers mean?

X-RateLimit-Limit is the maximum requests allowed in the current window, X-RateLimit-Remaining is how many you have left, and X-RateLimit-Reset is when the window resets (here shown as seconds remaining). They let clients self-throttle before hitting a 429.

When should I send the Retry-After header?

Send Retry-After only with a 429 Too Many Requests (or 503) response. It tells the client how many seconds to wait before retrying. This tool sets it to the number of seconds until the current fixed window resets, rounded up.

What is a burst allowance?

A burst allowance is extra capacity on top of your steady-state limit, letting clients briefly exceed the base rate to absorb spikes. In this tool the effective cap shown in X-RateLimit-Limit is the base limit plus the burst, and requests beyond that cap in a window are rejected.

Does this use a fixed window or sliding window?

It models a fixed-window limiter: the counter resets at the start of each window, which is simple and matches many gateways. Fixed windows can allow up to twice the limit across a window boundary; if that matters, consider a sliding-window or token-bucket algorithm.

Should rate limits be per IP, per user, or per API key?

It depends on your threat model. Per-API-key limits are usual for authenticated APIs because they map to a billable identity; per-IP limits protect unauthenticated endpoints but can punish users behind shared NAT. Many APIs combine both, applying the stricter of the two.

API Rate-Limit Header Calculator

Before you ship a rate-limiting policy, it helps to see exactly what your API will tell clients. This tool simulates a stream of requests against a fixed-window limiter and prints the precise X-RateLimit-* and Retry-After header values for every request — so you can verify the policy and explain it in your docs.

How it works

The simulator implements a fixed-window counter. Time is divided into windows of the duration you set. Within each window the limiter allows up to an effective cap equal to your base limit plus any burst allowance, and reports that cap in X-RateLimit-Limit.

For each simulated request at time t:

Determine which window t falls in; if it has crossed into a new window, reset the counter to 0.
If the in-window count is below the cap, the request returns 200 OK, the counter increments, and X-RateLimit-Remaining becomes cap - count.
If the cap is reached, the request returns 429 Too Many Requests, X-RateLimit-Remaining is 0, and Retry-After is set to the number of whole seconds until the window resets (rounded up).

X-RateLimit-Reset is shown here as the seconds remaining until the current window ends; in production you may emit it as an absolute Unix timestamp instead.

Example

With a limit of 5 per 10 seconds, no burst, and a client sending one request per second: requests 1–5 return 200 with remaining counting down 4, 3, 2, 1, 0; requests 6–10 return 429 with Retry-After shrinking as the window reset approaches; at t = 10s the window resets and request 11 returns 200 again.

Notes and tips

Always return Retry-After on a 429 so well-behaved clients back off instead of hammering you.
Fixed windows can permit a burst of up to 2 × limit straddling a window boundary. If you need smoother enforcement, use a token bucket or sliding-window log.
Document your headers publicly. Clients that read X-RateLimit-Remaining can pace themselves and generate far fewer 429s.
Apply limits at the identity that matters (API key, user, or IP) and consider separate, tighter limits for expensive endpoints like search or auth.