Rate Limit

A rate limit is the cap an API puts on how many requests you may send in a window: 100 per minute, 5000 per hour, 10 per second per key. Go over and you get HTTP 429 Too Many Requests, usually with a Retry-After header telling you how long to sit down. Most providers also expose live headers like X-RateLimit-Remaining and X-RateLimit-Reset so you can steer before you hit the wall.

Under the hood it is normally a token bucket (you refill at a steady rate and can spend a burst) or a sliding window counter. That difference matters. A token bucket deliberately allows a burst up to whatever the bucket holds, then throttles you to the refill rate. A fixed window is the crude one: spend the whole minute's budget at 11:59:59 and the counter resets at 12:00:00, so you can fire double the intended rate straight across the boundary. A sliding window smooths that seam out by counting the trailing period instead of a block aligned to the clock. When you build the limit yourself, put it in front of anything expensive or abusable: login, signup, search, password reset, LLM calls.

The classic self-inflicted wound is retrying immediately on a 429, which just spends the next window's budget and can turn a blip into a retry storm. Back off exponentially with jitter, respect Retry-After when it is present, and batch or cache instead of looping one call per row. Also check what the limit is keyed on: per API key, per IP, per user, or per endpoint are four very different budgets, and some providers meter cost or tokens rather than request count.