When the only lever is the big switch
It's late on a weeknight. One of your customers has something on their side calling your API far more than it should. Maybe a sync job is stuck retrying. Maybe someone set up an AI agent, pointed it at your tool and went home.
You open your admin panel to deal with it. Then you notice something uncomfortable. Almost every control you have works on the whole customer, not on the one thing that's misbehaving.
This post is about that gap: why it exists, and what smaller levers look like.
The levers most teams actually have
If you sell an API, an MCP server or a dev tool, your options in that moment usually look something like this:
- Revoke or rotate the customer's API key. This works right away, but if the customer uses one key for everything, every integration they run stops with it.
- Suspend the account. It's clean and it's fast, and it's the biggest switch of all.
- Turn down a rate limit. This slows the runaway caller, but it slows the customer's healthy traffic too, and it may not stop the cost if the expensive part is what each call does.
- Let the plan's hard limit kick in. A hard stop on the plan feels like a safety net. When it trips, though, it trips for the account, so the integration that behaved itself all month goes dark next to the one that didn't.
- Contact the customer and wait. This is the friendliest option and often the right one, if someone on their side answers before the damage is done.
Look at that list again and notice how many of those options act on the account. Only the last one is precise, and it depends on another company's on-call rotation.
So teams end up choosing between two bad outcomes. You can leave it running and absorb the cost or the load, or you can flip the big switch and break things the customer cares about. Neither one is a good start to the conversation you're about to have.
Why the switch is so blunt
None of this happens because teams are careless. It comes from a few reasonable decisions made early on.
Keys were designed for customers, not for callers. When most API traffic came from a person's app or a single backend, one key per customer was plenty. Today one customer might run a nightly data sync and a couple of AI agents, all on the same key.
Limits are counted where billing happens. Plan limits often live next to invoicing, which counts usage per account and usually after the fact. That's the right place to bill. It's a hard place to make a quick, narrow decision about one caller.
Software doesn't slow down on its own. A person using your product has a natural pace. A script or an agent doesn't stop to wonder whether it has done enough. When something goes wrong on the caller's side, it keeps going at full speed until something outside it says no.
Put those together, and the smallest thing you can stop is often the whole customer.
A quick check you can run this week
You don't need new tools to find out where you stand. Take one real customer and work through these questions with whoever is on call:
- How many separate integrations or agents does this customer run against us? If you don't know, that's the first finding.
- Can we tell which one made a given call? Look for a key, a header or anything else in your logs that separates them.
- If one of them ran wild right now, what is the smallest thing we could stop? Be honest about whether the answer is a single key or the whole account.
- Who on our side can do that at 2 AM, and how? If it means a database change, write that down.
- What would the customer's software see when we stop it? A clear, specific error lets their team fix it. A generic failure starts a support ticket.
If the answers to questions 3 and 4 make you wince, you're in good company. It's a story we've heard in our conversations with API and tool teams.
What smaller levers look like
The fix is mostly about where you draw lines, not about new technology. A few patterns help:
Give each integration or agent its own key. This is the foundation. Once each caller has its own key, "stop that one" becomes a real option. It also makes your logs far more useful when a customer asks what happened.
Put the limit on the key, not only the account. The account plan can still set the overall budget. A limit per key means one runaway caller hits its own ceiling while the customer's other integrations keep working.
Check before the work, not after. A limit that's counted at invoice time can only tell you what already happened. A quick check before your tool runs can say no before the expensive part starts.
Watch before you block. When you add a new limit, run it in a mode that only logs what it would have stopped. A week of that tells you whether the number is right before any customer feels it. (This is how shadow mode works in Ordainer Cap: new plans start there, and nothing is blocked until you switch it on.)
Keep a record you can show the customer. For each stop, keep which key was stopped and why. That turns the follow-up call from an argument about usage into a short, factual conversation.
The conversation afterwards
The real cost of the big switch isn't the downtime. It's the call that comes next.
"We turned off your account" is hard to recover from, even when you were right. "We paused your nightly sync because it was looping, and everything else kept running" is a call most customers are glad to get. It shows you were watching out for them, and it keeps the relationship and the revenue intact.
That's the goal: when something on a customer's side goes wrong, you can stop the one thing that's broken and leave the rest alone.
Try it on your own API. Our team builds Ordainer Cap, a check your API or MCP tool calls before it does the work, so a limit can stop one key instead of a whole customer. You can try it with a free test key, no credit card needed. Sign up at ordainer.ai.
Would you rather talk it through with us first? Email sales@ordainer.ai.
Had to flip the big switch on a customer? We'd like to hear how it went. Tell us your story in a short survey.
The Ordainer team