Free tool

API rate limit simulator

Pick an algorithm, set your limit, window and burst size, and throw a request pattern at it. See which requests get through, how many get a 429 Too Many Requests, when the first one hits, and what Retry-After to send back. The table underneath runs the same traffic through all three algorithms so you can compare.

Related free tools: plan limit & overage calculator (monthly quotas) · endpoint normalizer · usage pricing calculator.

1. Your limit

Algorithm

Limit (requests per window)

Window (seconds)

Burst / bucket size (token bucket)

2. Request pattern

Pattern

Steady rate (requests/second)

Duration (seconds)

Spike / burst size (requests)

Spike every (seconds)

Custom request times in seconds (comma or newline separated; used when Pattern = Custom)

3. Results

Requests

Allowed

Rejected (429)

First 429 at

Suggested Retry-After

Timeline ( per bar):allowedrejected (429)

Same traffic, all three algorithms

Algorithm	Allowed	429s	First 429	Retry-After

Suggested Retry-After is the 95th-percentile wait (rounded up to whole seconds) until a rejected request would have been allowed. Token bucket refills at limit ÷ window per second up to the burst size and starts full. Capped at 20,000 simulated requests. Runs entirely in your browser; nothing you type is sent anywhere.

The link in your address bar saves this scenario, so you can bookmark or share it.

Embed this simulator

Free to embed in your API docs or blog. Copy this:

<iframe src="https://api-meter-lab.pages.dev/embed/api-rate-limit-simulator" width="100%" height="980" style="border:1px solid #e3e6ec;border-radius:10px" loading="lazy" title="API rate limit simulator"></iframe>
<p><a href="https://api-meter-lab.pages.dev/api-rate-limit-simulator">API rate limit simulator</a> by API Meter</p>

Which algorithm should you use?

Token bucket allows short bursts up to the bucket size, then holds clients to the average rate. Good default for public APIs.
Fixed window is the simplest to build (one counter per window), but a client can send up to twice the limit across a window boundary.
Sliding window (log) enforces the limit over any rolling window exactly. It costs more memory, since it keeps a timestamp per allowed request.

Whatever you choose, send Retry-After with every 429 so well-behaved clients back off instead of hammering you.

To set limits that fit, you need real request rates per customer and endpoint. API Meter shows them without an SDK: route your API through the proxy and tag each response with a customer ID and plan. Note that API Meter measures traffic; it doesn't enforce rate limits for you.

See your real per-customer request rates, free Integration guide