Fill out a form too quickly and a red banner appears: "Too many requests. Please wait." Try a wrong password five times and your account locks. Build an automation that fires against an external API two hundred times in a minute and the calls start failing halfway through. These are the same mechanism at work. It is called rate limiting, and once you understand it, it stops being a frustrating mystery and starts making complete sense.
A Barista Who Can Only Make 60 Coffees an Hour
Imagine a coffee shop with one skilled barista. She is excellent at her job. But she can physically make at most 60 cups an hour while maintaining quality. If 200 people walk in at once and all order simultaneously, she has a choice: try to serve all 200 at the same time (and produce poor coffee for everyone, run out of supplies, and burn out), or pace things deliberately by telling some customers to wait, serving them in order, and delivering something good.
That second choice is rate limiting.
A server running a web application or an API faces the same constraint. It has finite memory, processing capacity, and bandwidth. If it tried to respond to every single request the moment it arrived, with no ceiling, it would quickly become overwhelmed. Responses would slow to a crawl. The service would become unreliable for everyone at once, including the users who were being perfectly reasonable about their usage.
Rate limiting is how software manages that ceiling deliberately, rather than letting chaos manage it by accident.
Why Every Serious System Uses This
There are three reasons you find rate limiting on almost every API, every login form, and every free-tier service:
Fairness. Without a ceiling, a single heavy user can consume most of a shared resource. One automation script running without pause could pull data from a shared API faster than the next 500 users combined. Limits ensure that one person's usage does not degrade the experience for everyone else on the same infrastructure.
Security. Rate limiting is one of the simplest and most effective defenses against brute-force attacks. If someone writes a script to try thousands of password combinations per second against a login form, a rate limit stops that script cold. After a small number of failed attempts, further tries are blocked for a period. This is why online banking locks an account after three wrong PIN entries. The limit is deliberately low because the cost of a legitimate user being temporarily locked out is far lower than the cost of an account being compromised by an automated attack.
Cost control. Servers are not free. Every request consumes real compute and bandwidth, both of which cost money. Imposing limits lets a service offer a free tier without a single user accidentally (or deliberately) consuming thousands of dollars of capacity. When a SaaS tool says you can make 100 API calls per day on the free plan, that is the business model expressed as a technical constraint.
How the Counting Actually Works
You do not need to understand the full internal algorithms to work with rate limits sensibly. But one mental model helps enormously.
Imagine a bucket with a small hole in the bottom. The bucket fills with tokens at a fixed rate, say 10 tokens per second. Each request you make takes one token out. If you make requests faster than new tokens arrive, the bucket empties and the system starts refusing requests until it refills.
This model is literally called a "token bucket" and it is one of the most widely used approaches in practice. The key property is that it allows short bursts. If you have not made any requests for a while, your bucket fills up. You can spend those accumulated tokens quickly. But sustained heavy use eventually empties it and triggers the limit. Moderate, steady usage stays under the ceiling. Sudden spikes are tolerated up to a point. Only relentless hammering gets refused.
Another common approach is a sliding window. Instead of a bucket, the system looks back and asks: how many requests arrived from this source in the last 60 seconds? If the count exceeds the allowed number, the next request is refused until old ones fall outside the window. Same idea, slightly different math, same outcome for the person on the other end.
What the Error Looks Like
The standard HTTP status code for hitting a rate limit is 429, officially called "Too Many Requests." You may see it as a terse message in a browser, as a developer's error log entry, or as a user-facing banner like "You have made too many requests. Please wait a moment."
Well-implemented APIs also include a Retry-After header in the response, which tells the caller exactly how many seconds to wait before trying again. A well-written application reads that header and waits the specified time. A poorly-written one ignores it and retries immediately, which just gets refused again and again until the client gives up or the window resets.
The error is not a bug in the service. It is the service working exactly as designed. The question to ask is not "why is this broken?" but "how much time do I need to wait, and how do I avoid hitting this again?"
Where You Run Into This in Practice
Once you know what to look for, rate limits are everywhere:
Email platforms cap how many messages can be sent per hour to protect their sending reputation and server load. Import 10,000 new contacts and try to email them all immediately and the platform paces the sends automatically, whether you asked it to or not.
Social media APIs publish explicit limits on how many reads or writes a developer application can make per 15-minute window. The dashboards for developers show current usage against those limits in real time.
Login forms on anything security-sensitive lock out further attempts after a small number of failures. The limit is intentionally aggressive because the cost of a real user being temporarily inconvenienced is far lower than the cost of an automated credential-stuffing attack succeeding.
Automation tools like Zapier impose execution limits based on your plan tier, and many of the APIs those tools connect to have their own limits on top. I have hit these building workflows that need to query a CRM across a large contact list. The fix is almost always the same: add a short delay step between iterations so the workflow spreads its requests across time rather than firing them all at once. Five hundred API calls spread over five minutes is almost always fine. Five hundred calls in five seconds is not.
What to Do When You Hit One
If you are a regular user, wait the specified time and try again. The service is not broken, you are not in trouble, and the limit will reset. A rate limit is a temporary queue, not a permanent ban.
If you are building automation, read the API documentation before you start. Every serious API publishes its rate limits prominently, often with code examples for handling them. Design your workflow to stay comfortably inside those limits. Build in retry logic that waits before retrying rather than immediately hammering the endpoint again. If you are processing large volumes, break the work into batches with deliberate pauses between them. The most reliable automations are not the fastest ones, they are the ones that pace themselves.
If you are comparing pricing tiers on a tool, pay close attention to rate limits alongside the storage and user counts. A plan that allows only 500 API calls per day sounds generous until you calculate what your actual usage requires. The number on the pricing page tells you the constraint you are buying into.
Rate limits are not an obstacle. They are the contract between you and the infrastructure that makes everything run reliably. Understanding them makes you a better user of any tool, and a significantly better builder of the automations that connect them.
If you are building or auditing automations and want a second set of eyes on where the limits are likely to bite you, get in touch.