Rate Limiting Your Public API: A Cost Breakdown

Most public APIs are not taken down by a sophisticated attack. They get bled dry by something dull: one scraper, one reseller, or one customer who wired a while-true loop into your /search endpoint. The teams that feel it first are small ones — a five-person engineering team running a B2B portal that someone decided to expose as an API. No security engineer, no on-call rotation, and a cloud budget meant to stay under ₹50,000 a month.

The instinct is to ask what rate limiting costs. The honest answer: the tooling is cheap, the abuse is expensive, and most of the expense lands somewhere you were not watching.

The four layers, and what each one costs

Almost nobody needs all four on day one. Knowing the price of each keeps you from over-buying.

• Edge and WAF. Cloudflare's paid tier runs around $20/month per domain; AWS WAF is roughly $5 per web ACL per month, $1 per rule per month, plus about $0.60 per million requests inspected. This stops scanners and known bad IPs before they touch your servers. It does not understand your tenants.
• Gateway limits. NGINX limit_req, Kong, or AWS API Gateway usage plans. Effectively free if you already run them, but the limits are blunt: requests per minute, per key or per IP. A floor, not a policy.
• Application-level token buckets. A Redis instance holding per-tenant, per-endpoint counters. In ap-south-1, a small managed Redis is roughly ₹900–1,300 a month. This is the layer that reflects your product: search costs more than a profile lookup.
• Identity and verification. OTP, email verification, domain ownership checks. These cost money every time they run, which makes them a favourite target.

A worked example: 40,000 requests a day

Take a mid-market B2B portal. Around 40,000 API requests a day, roughly 1.2 million a month, from 200–300 customer accounts. Then someone points a scraper at /search and it climbs to 800,000 requests a month — two-thirds of your total traffic.

Where the cost actually lands:

• Gateway and compute: 800,000 extra requests at roughly $3.50 per million is under $3 a month. Ignore this line.
• Database: each /search call runs a 40ms query across three tables. Your db.t4g.medium starts pinning above 65% CPU at peak, so you move to t4g.large and add a read replica. That is roughly ₹10,000–17,000 a month more.
• Latency: p95 for paying customers goes from 300ms to 900ms. Two enterprise prospects raise it on a call. That is the real invoice, and it never appears in your cloud bill.

So the abuse cost you perhaps ₹15,000 a month in infrastructure, plus one deal you will never be able to attribute to it. The fix — cost-weighted token buckets in Redis, per-key quotas, and alerts — is ₹900–1,300 a month in infrastructure and, in our experience, two to four days of engineering for a team already running a cache.

Where the money actually leaks

Server capacity is rarely the biggest line item. These usually are.

• OTP and message abuse. An attacker hammering your send-OTP endpoint with fake numbers bills you per message. In India, a transactional SMS after DLT registration typically runs ₹0.15–0.30; 100,000 requests in a night is ₹15,000–30,000, and your sender ID can get flagged by the operator. WhatsApp authentication templates are billed per message too, and Meta's India rates change — check them before you model this.
• Egress and upstream calls. If every request fans out to a paid data provider, a scraper is now spending your money on someone else's service.
• Sending reputation. If your API can send email or WhatsApp messages, an abuser turns you into their infrastructure. Your sending domain gets throttled, inbox placement drops for weeks, and your own transactional mail suffers with it.
• Support and incident time. A fully loaded engineer-day in Gurgaon is roughly ₹7,000–12,000. Three days a week of firefighting for a month quietly wipes out a year of Redis.
• Compliance exposure. If scrapers are pulling customer records, you are the data fiduciary under the DPDP Act, 2023, and claiming you did not notice is not a defence.

What to build first

Start blunt, then get precise.

• Require a key for every endpoint, including the free tier, tied to a verified email or domain. Anonymous public APIs are where the worst of this happens.
• Set two limits per key: a burst limit (say 20 requests per 10 seconds) and a daily quota. Treat IP as a secondary signal only — Indian carrier NAT means one IP can legitimately represent thousands of users.
• Weight your quotas. Charge 1 unit for a profile read, 20 for /search, 200 for /export. In practice this single change stops scraping without touching real customers.
• Harden the expensive paths separately: login, OTP, signup, password reset. Stricter limits than everything else, always.
• Alert on per-key outliers, not averages. Averages hide exactly the abuse you are trying to catch.
• Fail open, log loudly. If Redis is unavailable, serve the request and record the overage. An outage caused by your own rate limiter is worse than the scraping it prevents.

Where to start

Pick the one endpoint that costs you the most per call, put a cost-weighted token bucket in front of it, and alert on the top ten keys by volume. That single afternoon of work catches most of what actually happens. If you would rather not run it yourself, Maysan Labs builds this kind of middleware — rate limiting, key management and abuse dashboards — alongside the web platforms and portals we ship for teams in India and the UK.