A shared team balance works fine until spend stops matching expectations. An account with no split by employee or task can't answer who spent what until someone opens the transaction history line by line. Here is how to cap spend with keys, thresholds and directions — and spot the process burning budget faster than the rest.

Why a shared balance drains unnoticed without limits

One balance for the whole team works fine until the first mistake. Once several employees or automated processes draw on it, charges happen in parallel, and the only way to see it is after the fact, once the balance is already near zero. A shared balance with no split answers "how much is left", not "who spent it".

API spend needs no confirmation at each step: a script that fires off a thousand activations in a row gets charged for all of them, and the first to notice is usually not its author but whoever's task just ran out of balance. A cap isn't about distrusting employees — no one watches a live spend counter in real time.

Separate keys with different limits: splitting by employee and task

The working pattern is one API key per employee or per task — bulk registration, monitoring, a test environment — rather than one key for the whole team. Each key carries its own spend cap, so a failing process doesn't block the rest or eat into another task's budget. Key setup is covered in the API docs.

Splitting by key also settles accountability: if spend on one key goes past normal, it's immediately clear which process or employee caused it, without combing through the shared history line by line. A compromised or misbehaving key can be disabled on its own, without stopping the rest of the team's work.

Daily and monthly spend thresholds

A single cap for the whole period misses a fast burn: if the monthly threshold is five hundred units and a broken process spends that in three hours, the cap only stops it once the budget is at zero. A daily threshold catches the problem the same day, not at month's end.

Keep both at once: the daily cap limits how fast a key can burn through funds, the monthly cap limits the overall budget for a task or employee over the period. Set the daily cap with headroom for normal load, not right at the edge, or it will block legitimate work on busy days.

Monitoring by direction and threshold alerts

A direction is a country-plus-service pair, and spend is almost never spread evenly: one or two directions usually eat a disproportionate share of the budget. Monitoring spend by direction, not just the total, quickly shows which combination is dragging the budget down.

An alert that fires once the limit is exhausted is useless — the task has already stalled. Use a staged alert instead: a notice at 70–80% of the threshold gives time to investigate, and a second at 95% signals it's time to pause non-critical processes manually. Both thresholds need to sit at the key level, not the shared balance, or the alert arrives too late again.

The typical scenario: a retry loop on a dead direction burns budget in hours

A common incident: a direction that delivered codes reliably yesterday suddenly stops delivering SMS at all — a carrier switched a route, or the direction went down at the supplier's end. A process that auto-retries on a cancelled activation can't tell bad luck from a dead direction: it just orders another number, again and again, and every attempt gets charged.

Without a daily cap on the key, a loop like that can burn a week's budget in a few hours. That's why the transaction history is worth checking weekly not just for the total spent, but for runs of consecutive cancellations on one direction: three to five cancellations in a row on the same country-service pair is a signal to stop that direction, not retry it.

Frequently Asked Questions

How many keys should one team set up?

The rule of thumb is one key per employee or per standalone process, not one shared key for the whole team. Splitting makes sense as long as each key maps to an area of responsibility rather than becoming a formality.

What if a key's limit runs out mid-task?

A one-off increase for that key is usually faster and safer than removing the cap entirely — a problem with one process shouldn't spill onto the team's other keys. A cap that's constantly too tight on an active task should be raised, not switched off.

How do you tell a normal spend spike from a burn on a dead direction?

A normal spike is spread across different directions and services. A burn is spend concentrated on one country-service pair with a high share of cancelled or failed attempts in a row, visible in that day's transaction history.

The full breakdown of charges by key and direction lives in transaction history: it shows exactly which key and direction to shut down first. Another hidden cost for teams — numbers sitting idle in a rental — is covered in auditing your number fleet.