What Is API Rate Limiting? How Apps Avoid Meltdowns

Open any app and tap a button too many times too fast — refresh your feed, hit "check order status" over and over, retry a failed payment five times in ten seconds — and eventually you'll get a blunt reply: "Too many requests, try again later." That's not the app glitching. That's a deliberate wall called rate limiting, and it's one of the quiet reasons the internet doesn't fall over every time something gets popular.

What an API Actually Is, and What Rate Limiting Does to It

An API, or application programming interface, is just the agreed-upon way two pieces of software talk to each other. When your banking app shows your balance, it isn't reading your bank's database directly — it's sending a request through an API, and the bank's server sends back an answer. Every tap, swipe, and refresh in a modern app usually fires off one or more of these requests behind the scenes.

Rate limiting is a server telling its callers: you can only ask me this many times in this many seconds. Cross that line and the server refuses the request instead of trying to process it anyway. It sounds almost rude, but the alternative is worse. A single buggy app, a script someone forgot to stop, or an actual attack can send thousands of requests a second. Without a limit, that traffic can slow the service down for every other user, or take it offline entirely.

The Four Ways Servers Say "Slow Down"

Most systems use one of a handful of well-established approaches, and each makes a different tradeoff between fairness and complexity:

• Fixed window: allow, say, 100 requests per user per minute, and reset the count when the clock ticks over to the next minute. Simple to build, but someone can send 100 requests in the last second of one window and another 100 in the first second of the next — a burst of 200 almost back to back.
• Sliding window: instead of a hard reset, the server keeps a rolling log of recent request timestamps and counts backward from right now. Smoother, but it costs more memory to track.
• Token bucket: each user gets a bucket that refills with tokens at a steady rate; every request spends one token. This is popular because it naturally allows short bursts while still capping the average rate over time.
• Leaky bucket: requests queue up and get processed at a fixed, steady pace, like water leaking out of a bucket at a constant drip regardless of how fast it's poured in.

A server that never learns to say no eventually loses the ability to say anything at all.

Why This Is a Very India-Specific Problem Too

Nowhere is this more real-world than in India's own payment rails. The National Payments Corporation of India (NPCI), which runs UPI, processes well over 16 billion transactions a month across hundreds of banks and apps. For years, a recurring headache was banks and third-party apps hammering NPCI's servers with repeated "check payment status" calls whenever a transaction looked stuck — users anxiously refreshing, apps auto-polling, all at once, during peak hours like salary day or big sale events. NPCI responded by mandating strict API rate limits: banks and payment apps are only allowed a capped number of status-check calls per transaction, and apps that exceed it can face penalties or throttling of their own access. It's rate limiting applied at national financial-infrastructure scale, and it's a big part of why UPI stays usable even when the whole country is paying for something at the same moment. If you want the fuller picture of how India's payment and financial-data plumbing is regulated, our explainer on India's Account Aggregator framework covers the same RBI-driven logic of controlled, permissioned access to systems that can't afford to buckle under load.

What This Means If You're the One Building the App

For developers — and India has one of the largest populations of them building against UPI, government, and cloud-provider APIs — getting rate-limited isn't a sign you've done something wrong. It's a sign the system is working as designed. A few practical habits make it painless instead of painful:

1. Read the provider's documented limit before you build, not after your app starts failing in production.
2. Use exponential backoff — wait a bit longer after each failed retry instead of hammering immediately again.
3. Cache responses that don't change often, so you're not re-asking for the same answer.
4. Watch for rate-limit headers in the response; most well-built APIs tell you exactly how many requests you have left before you even hit the wall.

The next time an app tells you to slow down, it's worth remembering that somewhere behind that message is an engineer who decided a graceful "not right now" beats a server that's crashed for everyone. That's a far better outcome than the alternative, even if it costs you a few seconds of waiting.