Nearly every support request about unexpected charges ends the same way: the key leaked. Not a hack, not a brute-forced password — a key that sat somewhere someone else could read it. Below are six rules that close out most of these stories.

First: the key lives in environment variables, not in code. A key string committed to a repository is a key published forever, even if you delete it in the next commit — history keeps everything, and public repositories get indexed by bots within minutes.

Second: never call the API from the browser. Any request from the frontend means the key can be read straight out of dev tools. Buying numbers has to go through your backend — hand the client only the result.

Third: separate keys by environment. The live key stays in production only; use a test key for development and CI. That way a leak from a test environment doesn't turn into a drained balance, and the logs immediately show where a request came from.

Fourth: restrict access by IP. If API requests only ever come from a couple of known servers, an allowlist makes a stolen key nearly useless. It's a five-minute setting that breaks most automated attacks outright.

Fifth: rotate the key at the slightest doubt. Showed it in a screenshot, pasted it into a chat, let go of a developer who had access — rotating takes a second and costs far less than untangling the charges afterward. The old key stops working immediately, so plan the update across every integration.

Sixth: turn on two-factor authentication on your account. The key can only be reissued from the dashboard, so login protection is the last line of defense — without a second factor, someone else's access to your email turns into full access to your balance.