An API key is not an integration detail, it is a payment instrument. Whoever holds the token spends your balance without further questions: the service checks the value, not the person behind it. A developer wires up billing, numbers, or proxies through the API and gets a secret that looks like an ordinary variable but is equivalent to a card with access to account funds. Below: where a key leaks most, where it belongs, how to split credentials, and what to do after a leak.
A key equals access to your balance
An API token does not prove identity — it proves the right to spend. The system checks only the value, not who sent it. If the string ends up with an outsider, the API sees an ordinary legitimate request: buying a number, renting a proxy, a charge against the balance — it all goes through as routine account activity. Theft looks identical to normal use, so the only real defense is keeping the secret out of the wrong hands, not detecting a substitution after the fact.
Where a key must never live
A secret leaks through the same handful of channels. In a code repository, a string committed "for a quick test" stays in version history forever — deleting the file later does not remove an earlier snapshot, and a public or shared repository turns that find into someone else's access within minutes. In a container image, a token baked into a build file or passed as a build argument settles into an image layer and travels with it to every registry, including looser staging setups.
In client-side page code, anything the browser receives and runs is readable by any visitor through developer tools, so a value calling the server without its own backend sits there as plain text. And in a request's URL, a secret placed in the path or a query parameter is copied everywhere the URL ends up — server and proxy logs, browser history, the referrer header, sometimes an error message that echoes it back. The right place for a credential is a request header, never the path.
Where a key belongs
The rule is simple: a secret must not exist as plain text in anything that gets committed. A running process reads the value from environment variables set at the server or orchestrator level, not from a file next to the source. A sample configuration file ships with empty placeholders; the real file never reaches the repository — it sits on the ignore list. Teams juggling several secrets need more than environment variables: a dedicated secret store that hands out a value on request, logs access, and revokes it without touching application code.
Separate keys per task and per person
One token for everything is the most common and most expensive shortcut. If a production server, a test script, and a partner integration share one value, revoking it after a leak shuts everything down at once — the live service stops along with the test setup that leaked. Split credentials by task — production, CI, local development, partner integration — and by person or team with access. Revoking one secret then answers a specific incident, not all of billing, and a credential's usage log shows which task is spending the balance, so an anomaly is localized fast.
Rotation: scheduled and emergency
Scheduled rotation means issuing a new secret and revoking the old one on a calendar, not after an incident. The order that avoids downtime: issue a new value without revoking the old one, roll it into the configuration, confirm requests succeed, then revoke the previous token.
When a leak is suspected, the order flips: revoke first, investigate after. Revoke a compromised key immediately, even without full certainty — downtime costs less than someone else's charges. Then pull the transaction history for the period it may have been compromised and check it against what your system actually did. If the secret sat next to other access — a server password, a token for a service like the proxy API — rotate those too, since a leak rarely stops at one value. For staying under request limits after a key change, see API rate limits and throttling.
Frequently Asked Questions
What should I do if a key has already shown up in a public repository?
Revoke it immediately, even if the commit is removed by the next one — version history keeps every version of a file. Issue a new key, update the configuration, and switch traffic over only after verifying it works; mark the old key revoked, not merely unused.
Can a key be scoped to one action instead of the whole API?
If the service supports scoped credentials — read-only balance access without spending rights — use those where full access is not needed. A scoped token limits the damage even in the wrong hands.
How often should keys be rotated if there has been no leak?
The cadence depends on how many people and systems hold access: the wider the circle, the shorter the safe interval. A reasonable baseline is rotating credentials at least once a quarter, plus right after anyone with access leaves.
The header format for a key, plus response codes for revocation and rate limits, is documented in the OTP API reference.