Almost every product today depends on someone else’s API: payments, email, maps, search, AI models, shipping rates. Every one of those APIs has a rate limit. And almost none of those limits show up during development, because development traffic is a handful of requests from a handful of people. They show up in production, usually the first week real users arrive, and usually at the exact moment traffic matters most.
Why Testing Doesn’t Catch It
Development and staging environments are built to verify that an integration works, not that it works at volume. A test suite that makes a few dozen calls confirms the request format is right and the response gets handled correctly. It says nothing about what happens when a thousand users trigger the same call inside the same minute. The limit exists the whole time. Nothing in the normal build process is designed to reach it.
Where It Actually Bites
Launches and promotions. The traffic spike you worked hardest to create is the one most likely to push an integration past its limit, which means the failure lands in front of the largest audience you’ll have all year.
Batch jobs that were fine at small scale. A nightly sync that loops through every customer record works perfectly with 500 customers. At 50,000, the same loop can burn through a daily quota in minutes, and it fails quietly at 2am where nobody’s watching.
Per-user features that multiply calls. A feature that makes one API call per page view looks cheap in isolation. Multiply it by every page, every user, and every refresh, and a single feature can quietly become the biggest consumer of a shared quota.
Free and entry-level tiers nobody revisited. A lot of integrations get set up on whatever plan was cheapest during the prototype phase. Those tiers often carry much tighter limits, and nobody goes back to check them before launch because the integration “already works.”
What a Rate Limit Failure Actually Looks Like
It rarely looks like a clean error. More often it looks like a checkout that intermittently fails, emails that silently don’t send, search results that come back empty for some users and not others. Because it only happens under load, it’s hard to reproduce after the fact, and it’s easy to misdiagnose as a bug in your own code rather than a ceiling on someone else’s.
How to Find It Before Your Users Do
Inventory every external API and its actual limit on your actual plan. Not the limit in the marketing page, the limit on the tier you’re currently paying for. This one spreadsheet catches a surprising share of launch-week failures on its own.
Estimate calls per user action, then multiply by realistic peak traffic. A rough back-of-the-envelope number is enough to spot the integrations sitting close to their ceiling.
Load test the integrations, not just your own servers. Most load testing focuses on whether your application can handle the traffic. The weaker link is often a third-party service that can’t, or won’t, at your current plan level.
Build graceful degradation for the calls that can wait. Queue what can be queued, cache what can be cached, and retry with backoff instead of failing outright. A rate limit hit should slow something down, not break it.
The Bottom Line
A rate limit is a known number sitting in someone else’s documentation, and it’s one of the most predictable production failures there is. It only feels like a surprise because nothing in a normal development process is built to reach it. Checking before launch is cheap. Finding out during launch is not.
Talk to VitaLink about production readiness for your integrations →