What Is a Rate Limit?
A rate limit is a cap on how many requests a user, app, or IP address can make to a server or API within a set time window — for example, 100 requests per minute. When the cap is exceeded, further requests are temporarily refused, usually with an HTTP 429 'Too Many Requests' response. Rate limits protect services from overload, abuse, and runaway costs, keep performance fair across users, and blunt attacks like brute-force login attempts and denial-of-service floods. Nearly every serious API and login system enforces them.
- What it is
- A cap on requests allowed per user, IP, or key in a time window
- Signal
- Exceeding it returns HTTP 429 Too Many Requests (MDN Web Docs)
- Common headers
- Retry-After and X-RateLimit-* tell clients when to try again (MDN HTTP headers)
- Purposes
- Prevents overload, abuse, scraping, and runaway API bills
- Algorithms
- Token bucket, leaky bucket, fixed and sliding windows are common
What a rate limit is #
A rate limit is a ceiling on how often something can be done in a given period. Applied to a website or API, it caps how many requests a single user, IP address, or API key may send within a window — commonly expressed as requests per second, per minute, or per day. Send requests under the limit and everything proceeds normally; cross it and the server temporarily refuses the extras, typically replying with an HTTP 429 'Too Many Requests' status until the window resets. You experience rate limits constantly without naming them: the login form that locks you out after several wrong passwords, the API that returns an error when a script loops too fast, the search box that asks you to slow down. The purpose is to keep a shared service stable and fair when demand or abuse spikes. Almost every reputable API publishes its limits. For businesses whose sites depend on third-party APIs, understanding these caps prevents features from breaking under load. Our /services/api-crm-integrations team designs integrations that respect each provider's limits.
Why services enforce rate limits #
Rate limits solve several problems at once, which is why nearly every serious service uses them. The first is stability: without a cap, a single buggy script or a sudden traffic surge could flood a server with requests and knock it offline for everyone. Limits keep one heavy user from starving the rest. The second is abuse prevention — limits blunt automated attacks such as password guessing, content scraping, and spam by making high-volume attempts impractically slow. The third is cost control: for services that pay per computation or charge customers per call, unlimited requests mean unlimited bills, so limits keep spending predictable. The fourth is fairness across pricing tiers, letting a provider offer more capacity on higher-paid plans. Together these make rate limiting a foundational tool for running any service at scale, not an inconvenience aimed at legitimate users. When your site sits behind good hosting, similar protections shield it from overload. Our /services/managed-hosting and /services/website-security pages explain how request limits and related safeguards keep your own site available under pressure.
How rate limiting works #
Behind a simple '100 requests per minute' rule sits one of a few well-known algorithms, and the choice affects how bursts are handled. The fixed-window approach counts requests in each clock minute and resets at the boundary; it is simple but allows a burst at the edge of two windows. The sliding-window method smooths that out by counting over a rolling period rather than a fixed clock tick. The token-bucket algorithm gives each client a bucket that refills at a steady rate; each request spends a token, so clients can burst briefly using saved tokens but are limited to the refill rate over time. The leaky-bucket variant instead drains requests at a constant pace, smoothing spiky traffic into a steady flow. Providers pick based on whether they want to allow short bursts or enforce a strict steady rate. You rarely need to know which one an API uses, but recognizing the concepts helps you interpret their documented limits. Our /services/web-app-development team implements these algorithms when building APIs that need protection from overload.
What a 429 response looks like #
When you exceed a limit, a well-designed API returns a 429 status with headers telling you how long to wait and how much quota remains. Clients should read these instead of blindly retrying.
HTTP/1.1 429 Too Many Requests
Retry-After: 30
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1799999999
Content-Type: application/json
{
"error": "rate_limited",
"message": "Too many requests. Retry after 30 seconds."
}Rate limiting vs throttling #
People use 'rate limiting' and 'throttling' interchangeably, but there is a useful distinction worth knowing. Rate limiting is usually a hard cap: cross the line and requests are rejected outright, typically with a 429, until the window resets. Throttling is softer — instead of refusing requests, the server deliberately slows them down, queuing or delaying them so the overall pace stays under control while still eventually serving them. A rate limit says 'no more until later'; throttling says 'I'll get to you, just slower.' Some systems combine both, throttling as load rises and hard-limiting only at the extreme. There is also a related idea, backpressure, where a system signals upstream callers to ease off before it is overwhelmed. For most business purposes the terms overlap enough that the distinction rarely matters day to day, but it explains why some APIs slow down under load while others return errors. When we build systems expecting heavy traffic, our /services/web-app-development team chooses whichever behavior keeps the experience smoothest for real users.
Rate limits and security #
Rate limiting is one of the most cost-effective security controls a site can have, because so many attacks depend on volume. Brute-force and credential-stuffing attacks try thousands of username-password combinations; a strict limit on login attempts per IP or account turns hours of guessing into years, often defeating the attack outright. Scrapers that try to vacuum up your entire catalog or customer directory are slowed to a crawl. Abusive form submissions and spam are curbed. And while dedicated denial-of-service floods usually need heavier defenses, basic rate limiting absorbs smaller ones and buys time. Because these protections work quietly at the request layer, they defend even against attacks that slip past other checks. Pairing rate limits with strong authentication and monitoring gives layered protection rather than a single point of failure. This is standard practice on any well-run site. Our /services/website-security page covers how we combine request limits, login protections, and monitoring so your forms, logins, and APIs resist the high-volume attacks that target small businesses most often.
Handling rate limits as a developer #
When your code calls an API that enforces limits, handling them gracefully separates a reliable integration from a flaky one. The first rule is to read the response: a 429 comes with a Retry-After header telling you exactly how long to wait, so the app should pause and try again rather than hammering the server. A common technique is exponential backoff — wait a second, then two, then four on repeated failures — often with a little randomness added so many clients do not retry in lockstep. Well-behaved code also watches the X-RateLimit-Remaining header and slows itself before hitting zero, spreading requests out rather than bursting. Caching results you have already fetched avoids needless repeat calls entirely. Ignoring these and blindly retrying can get your API key temporarily or permanently blocked. Building this politeness in from the start keeps integrations stable as they scale. Our /services/api-crm-integrations team writes connections that respect provider limits with proper backoff and caching, so your automations keep running instead of tripping over their own request volume.
Rate limits for small business sites #
Rate limits touch small businesses in two directions. Inbound, your own website benefits from limiting requests to protect login forms, contact forms, and any API you expose from abuse and overload — a quiet safeguard that keeps the site available and blocks spam. Outbound, your site consumes third-party APIs — payment processors, mapping, email, AI features — each with its own limits, and if your traffic grows or a feature gets popular, you can bump into them, causing errors for customers at the worst moment. The practical implications are to make sure your site's forms and logins are rate-limited against abuse, and that your integrations are built to handle provider limits gracefully rather than breaking. Neither requires you to manage anything technical yourself; it is about ensuring whoever builds and hosts your site accounts for it. If a feature intermittently fails under busy periods, hitting a rate limit is a prime suspect. A /free-website-audit can check whether your site and its integrations handle request limits sensibly.
Setting sensible limits #
If you run your own API, choosing limits is a balance between protection and usability, and getting it wrong in either direction hurts. Set the cap too low and legitimate users hit errors during normal use, generating support complaints and lost trust. Set it too high and it fails to stop abuse or control costs. Good practice starts by measuring how real users actually behave, then setting limits comfortably above that with headroom for bursts, tightening only where abuse appears. Different endpoints deserve different limits — a login endpoint should be strict to deter guessing, while a read-only data endpoint can be generous. Tiering limits by plan lets you offer more capacity to paying customers. Clear documentation and informative 429 responses with Retry-After headers help honest callers adapt instead of guessing. Reviewing limits periodically as traffic grows keeps them appropriate. This tuning is ongoing, not a one-time switch. Our /services/web-app-development team sets and revisits rate limits based on your real usage patterns, protecting the service without frustrating the customers it is meant to serve.
FAQ
What does HTTP 429 mean?
429 is the 'Too Many Requests' status code, returned when you exceed a server's rate limit. It signals that your requests were refused temporarily, not that anything is broken. A well-designed response includes a Retry-After header telling you how many seconds to wait before trying again, so the correct response is to pause, not to keep retrying.
How do I avoid hitting a rate limit?
Spread requests out over time instead of bursting, cache data you have already fetched to avoid repeat calls, and watch the X-RateLimit-Remaining header to slow down before reaching zero. When you do get a 429, honor the Retry-After delay and use exponential backoff rather than retrying immediately, which only makes things worse.
Are rate limits a security feature?
Yes, an important one. Rate limits blunt brute-force password guessing, credential stuffing, scraping, and spam by making high-volume attempts impractical, and they help absorb smaller denial-of-service attempts. They work best alongside strong authentication and monitoring, forming one layer of a defense-in-depth approach rather than a complete solution on their own.
What is the difference between rate limiting and throttling?
Rate limiting is usually a hard cap that rejects requests over the limit, often with a 429. Throttling is softer, deliberately slowing requests down so they are served more slowly rather than refused. Some systems use both — throttling as load rises and hard-limiting at the extreme. In casual use the terms often mean the same thing.
Does my website need rate limiting?
If it has login forms, contact forms, or any exposed API, yes. Rate limiting protects those from abuse, spam, and overload without affecting normal visitors. Most quality hosting and security setups include it. You do not manage it yourself, but you should confirm whoever builds and hosts your site has it in place.
Can rate limits block real customers?
If set too low, yes — legitimate users can hit errors during normal activity, which frustrates them. Good limits are measured against real usage and set with headroom for bursts, with stricter caps on sensitive endpoints like login and generous ones on ordinary reads. Limits should be reviewed as traffic grows to stay appropriate.
How Local Web Advisor checks this for you
Is your own website getting web tech right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web tech and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?