Naming and Scoping API Keys So Revoking One Breaks Nothing

Most people who connect a trading tool, a portfolio tracker or a spreadsheet to an exchange start with one API key. That key gets pasted into three or four places, nobody remembers which tool uses it, and the day you want to remove one integration you face a choice: leave the key alive or break everything at once. The fix is a naming and scoping habit that treats each key as belonging to exactly one tool. This guide walks through how to plan key names, decide permissions per tool, record what each key can do, and rehearse revocation so a single key can be deleted without touching the rest of your setup. It applies to Binance, OKX, Bybit and Bitget users in South Africa, and the exact menu labels, permission names and limit values should always be confirmed on the relevant help centre page for your exchange before you rely on them.

One key per tool, named so you can identify it months later

Before you create anything, write down the tools that need API access and what each one actually does. A charting tool that only reads balances is a very different object from a bot that places orders, and a tax or record-keeping tool is different again. Give each tool its own key rather than sharing one across all of them. The moment two tools share a key, revoking it for one tool silently breaks the other, and you will usually discover this at the worst possible time.

Name keys so a stranger reading the list could guess the purpose. A pattern that works well is a short tool label, the environment, and a date, for example a label that identifies the tool, a suffix such as read or trade, and the month and year the key was created. Avoid names like key1, main or test, because in six months none of those tell you anything. If the exchange lets you add a note or description to the key, use it for the same purpose and keep the wording consistent with your own records.

Keep the naming rule in a single place outside the exchange, such as a password manager entry or an encrypted note. The exchange key list is not a good archive: it may show only part of the name, and it will not tell you which tool is still using the key. Your own record should list the key name, the tool, the date created, the permissions granted, and the person or machine that holds the secret. Treat that record as the source of truth when you later decide what to revoke.

Choosing permissions per key instead of granting everything

The most common mistake is ticking every permission because it is faster than thinking about which ones are needed. Read access for a portfolio tracker, for example, does not need withdrawal rights or trading rights. A tool that only displays data should not be able to move funds, and a tool that trades should not be able to withdraw. Work through the permission list on the API management page and switch off anything the tool does not demonstrably use.

Where the exchange offers an IP allowlist or restriction, use it. If your tool runs from a fixed server or a known connection, restricting the key to that address means a leaked secret is far less useful to whoever finds it. If your tool runs from a home connection with a changing address, note that trade-off in your record instead of ignoring it, and check the help centre for how the exchange handles address changes and whether you need to update the entry.

Some exchanges separate permissions for spot and futures, or offer read-only modes and sub-account structures. Check the API documentation and the help centre for your exchange rather than assuming the options match another platform. If you use futures, review the futures product documentation as well, because the permission set and the risk profile are not the same as spot. Whatever you enable, write the exact permission names into your record so that a later review does not depend on memory.

Recording scope so revocation is a decision, not a surprise

For every key, your record should answer four questions: which tool holds it, what it is allowed to do, when it was created, and what breaks if it disappears. The last question is the one people skip, and it is the one that makes revocation safe. If the answer is nothing I care about, the key can be deleted at any time. If the answer is my nightly order bot, you know to expect that bot to stop and to plan the replacement before you revoke.

Review the list on a schedule rather than only when something goes wrong. A short monthly pass is enough: open the API management page, compare the live keys against your record, and flag anything you cannot match to a tool. Unmatched keys are the ones to remove first, because they are the ones you no longer understand. Also check the last-used information if the exchange shows it, since a key that has not been used in a long time is usually a candidate for removal.

Keep the record honest about ownership. If a key was created for a service, a contractor or a shared machine, say so explicitly, including who can read the secret. Shared secrets defeat the whole point of per-tool scoping, because you cannot revoke one person's access without affecting everyone else. Where possible, move shared use onto separate keys so that each person or machine has its own entry in the list.

Rehearsing revocation so one key can go without collateral damage

A revocation drill is simple: pick one key that belongs to a single tool, delete it, and watch what stops. Do this at a time when a short outage is acceptable, and tell anyone who depends on that tool beforehand. The goal is to confirm that only the intended tool is affected. If something unrelated stops working, you have just found a hidden dependency, and you can fix the scoping before a real incident forces the issue.

When you revoke, follow the exchange's own flow on the API management page and confirm the key is gone from the list, not merely disabled. If the exchange distinguishes between disabling and deleting, understand which one you have done, because a disabled key may still exist and reappear in a later review. If the tool needs to keep working, create a fresh key with a new name that reflects the new date, and retire the old name in your record rather than reusing it.

After the drill, update the record and note what happened. If you had to recreate a key, check whether the tool needs its secret re-entered and whether any IP restriction must be reapplied. If you found a tool sharing a key with another, split them now. Repeat the drill periodically with a different key so that no single key quietly becomes load-bearing again. For anything you cannot resolve from the interface, the exchange help centre is the place to check the current behaviour rather than guessing.

Risk boundary: South Africa Crypto Guide

Digital assets are volatile and derivatives can amplify losses. This website has no login, wallet connection, deposit form or customer-support chat. A referral link only records attribution; it does not guarantee access, pricing, rewards, approval or investment results. Availability can differ by residence, legal entity and product, so no regional access is assumed from language or branding alone.

Scenario checkpoint

• List every tool that uses API access and assign each one its own key before creating anything new
• Name each key with a tool label, a purpose suffix and the creation month so it is identifiable later
• Disable permissions the tool does not use, and apply an IP restriction where your connection allows it
• Record the key name, tool, permissions, creation date and what breaks if the key is revoked
• Run a revocation drill on one single-tool key and confirm nothing unrelated stops working
• Review the live key list against your record monthly and remove keys you cannot match to a tool