API Rate Limiting: Handle 429s, Then Set Your Own

Quick answer: API rate limiting caps how many requests a client can make in a time window. As a consumer, read the x-ratelimit-remaining and retry-after headers, back off exponentially with jitter on a 429, and authenticate wherever you can, because a key almost always buys a bigger quota. As a producer, use a token bucket, publish your limits in headers, and return 429 rather than 403.

The part most guides skip is that your quota depends on whether the API knows who you are. We can put a number on that, because we run the directory: of the 1,598 public APIs currently published on publicapis.dev, 639 (40.0%) require no authentication at all. Every one of those puts you in a shared bucket keyed on your IP address, with no quota you can raise and usually no dashboard to check. All figures here were computed on 18 August 2026.

What is API rate limiting?

Rate limiting is a server refusing work it could technically do, to protect capacity it needs for everyone else. A limit has three parts: a quota (how many requests), a window (per second, minute, hour or day), and a key (what the quota is counted against, usually an API key, a user ID, or an IP address).

That third part is the one that decides your experience. A quota counted against your API key is yours. A quota counted against your IP address is shared with everyone behind that address, including the rest of your office, your CI runners, and whoever else is on the same cloud NAT.

Why do keyless APIs limit you harder?

Because an IP address is the only identity they have, and it is a bad one. The keyless share of our directory is not evenly spread, and the pattern says something about who publishes what:

| Category | Keyless APIs | Share | |---|---|---| | Science & Math | 24 of 30 | 80.0% | | Health | 20 of 26 | 76.9% | | Government | 64 of 85 | 75.3% | | Games & Comics | 59 of 89 | 66.3% | | Finance | 13 of 64 | 20.3% | | AI | 1 of 31 | 3.2% |

Public-good publishers (research bodies, health agencies, governments) mostly skip keys, so their limits are anonymous, strict, and enforced per IP. Commercial categories do the opposite: in the AI category, 30 of 31 APIs want a key before they answer, because the request costs them real money and they intend to meter it.

The practical consequence: the friendliest-looking APIs, the ones you can curl with no signup, are the ones where you have the least control over your quota. For the full picture of who asks for what, see our breakdown of API authentication methods.

How do you find out what your limit is?

Check the response headers before you read the docs, because headers are current and docs often are not. The common ones are x-ratelimit-limit, x-ratelimit-remaining and x-ratelimit-reset, plus retry-after once you have been throttled.

GitHub is the clearest worked example, and it shows the authentication effect exactly. Checked against GitHub's own documentation on 18 August 2026: unauthenticated requests get 60 requests per hour, while a request carrying a personal access token gets 5,000 per hour. That is not a discount, it is roughly 83 times more capacity for the cost of sending a header. GitHub reports the state in x-ratelimit-remaining and x-ratelimit-reset (UTC epoch seconds), and returns either 403 or 429 once you are over.

Some limits are not in headers at all. Nominatim, the OpenStreetMap geocoder, publishes an absolute maximum of 1 request per second in its usage policy, and separately requires a User-Agent or Referer that identifies your application, explicitly rejecting the stock user agents HTTP libraries send by default. Break either rule and you are blocked rather than throttled. Policy limits like this are why "it returned 200 in testing" is not evidence you are within the rules.

What should you do when you hit a 429?

Handle it as a normal, expected response, not an error path you bolt on later.

1. Honour retry-after if it is present. It is the server telling you the answer. Sleeping for that duration is always better than guessing.
2. Otherwise back off exponentially, with jitter. Wait 1s, 2s, 4s, 8s, and add a random fraction to each. The jitter matters more than the exponent: without it, every client that got throttled at the same moment retries at the same moment and recreates the spike.
3. Cap the retries and the total wait. Three or four attempts, then fail loudly. A request that silently retries for ten minutes is worse than one that errors.
4. Treat 403 with x-ratelimit-remaining: 0 as a 429. Several large APIs, GitHub included, use 403 for rate limiting. Matching only on 429 will send you into a retry loop against a limit you are already over.
5. Cache, and make conditional requests. A response served from your cache costs nothing. Where an API supports ETag or If-Modified-Since, a 304 usually does not count against the quota.

The single highest-return change is still authentication. If an API offers a free key, take it, even for a hobby project.

How should you rate limit your own API?

If you are shipping the API rather than consuming it, four decisions cover most of it.

Pick a token bucket. A fixed window is easy to implement and lets a client fire the whole quota in the last second of one window and again in the first second of the next, which is double your intended peak. A token bucket refills continuously and absorbs short bursts without allowing sustained overload. A sliding window log is more precise but stores every timestamp, which gets expensive fast.

Key the limit on identity, not just IP. Limit per API key first, and fall back to IP only for anonymous traffic. Shared NATs mean an IP-only limit punishes large legitimate users and barely inconveniences a determined abuser.

Publish the state in headers, on every response. x-ratelimit-limit, x-ratelimit-remaining, x-ratelimit-reset, and retry-after on the rejection. A client that can see its own quota will pace itself. A client that cannot will hammer you and find out by accident.

Return 429, and document the numbers. Use 429 Too Many Requests for throttling, and keep 403 for authorisation. Then write the actual limits in your docs, next to your versioning policy and the rest of your REST API best practices. Undocumented limits get discovered in production by someone who will not enjoy it.

FAQ

What is a good API rate limit? There is no universal number, but a common shape for a free tier is 60 requests per minute per key with a short burst allowance, and a daily ceiling on top. Start from what one honest client needs for its worst realistic page load, multiply by a safety factor, and adjust once you have traffic. Publishing a lower limit and raising it is much easier than the reverse.

What is the difference between 429 and 403? 429 Too Many Requests means you sent too much and should retry later. 403 Forbidden means the server understood you and refuses regardless of timing. The confusion exists because some APIs return 403 for rate limiting anyway, so check x-ratelimit-remaining before deciding which one you actually got.

Does rate limiting apply per IP or per API key? Whichever the publisher chose. Authenticated requests are normally counted per key, and anonymous requests per IP. That distinction is why keyless APIs feel stricter, and why 639 of the 1,598 APIs in our directory offer you no way to raise your quota.

How do I test rate limiting without getting blocked? Test against your own service, or against an API that explicitly allows it, and use small deliberate bursts rather than load-testing someone else's free endpoint. Our guide to testing an API covers building that into a normal test suite.

Do rate limits count failed requests? Usually yes. Most implementations count every request that reaches the limiter, including ones that return 400 or 404, because the cost being protected is the request handling itself. A buggy client that retries 404s can exhaust a quota without a single successful call.