An API key is a spare set of permissions handed to software. Which permissions to grant, which to refuse outright, and how to check what you actually issued.

What an API key is

An exchange API key is a credential that lets software act on your account without your password. It comes with permissions, and those permissions are the whole story:

  • Read — see balances, positions, and trade history. Cannot change anything.
  • Trade — open and close positions on your account.
  • Withdraw / transfer — move funds out.

A key is not "your account" and not "your money" — it is exactly the set of rights you attached to it. Issue it carelessly and it becomes both.

The rule that follows: grant read, refuse everything else, unless you are running a trading bot you wrote or chose deliberately, in which case grant trade and never withdrawal.

Why read-only is the whole point

Verification services, portfolio trackers, tax tools and rating platforms all want the same thing: proof of what happened on your account. That is a read problem. Nothing about proving a track record requires the ability to place a trade.

So when a service asks for trade permission "to verify your results", the request does not match the stated purpose. It is not necessarily malicious — some products are built lazily and ask for everything — but you are the one carrying the consequence, and there is no version of a verification workflow that needs to be able to open positions.

This is how our own connection works, and we enforce it rather than describe it: when a key is submitted, we ask the exchange what that key is allowed to do and refuse the connection outright if it carries trade or withdrawal rights. The key never enters our system at all until the permissions come back clean. Stored keys are encrypted with a master secret that lives in the server environment, not in the database — a database dump on its own does not yield anyone's key.

Issuing a key correctly

The exact menu differs by exchange, but the checklist does not:

  1. Create a new key per service. Never reuse one key across two products. When you need to revoke, you want to revoke one thing, not audit five.
  2. Enable read only. Uncheck trade. Uncheck withdrawal, transfers, internal transfers, and sub-account movement. If withdrawal cannot be disabled on your account tier, do not issue a key at all.
  3. Bind it to an IP if the service supports it. An IP-restricted key is useless to anyone who steals it from somewhere else.
  4. Name it after the service. Six months later, "key 3" tells you nothing and you will leave it in place rather than risk breaking something.
  5. Copy the secret once. Exchanges show the secret exactly once. Store it in a password manager, not in a chat with yourself.
  6. Set an expiry where the exchange offers one, and rotate on a schedule you will actually keep.

Then verify what you issued, from the other side: if a key you believe is read-only can place a test order, the permissions are not what you think they are.

Signs a request for access is not legitimate

  • It asks for withdrawal permission. There is no legitimate third-party reason. This is the single unambiguous red line.
  • It asks for your exchange password or 2FA code. An API key exists precisely so this is never necessary. A request for either is an account takeover in progress.
  • It asks for your wallet seed phrase. Different credential, same answer, more final. See Crypto wallets explained.
  • It arrives by direct message with urgency. Support that contacts you first, after you posted about a problem, is not support.
  • The tool is a downloadable "verification helper". A verification that requires running an executable is not verifying, it is installing.

Securing the account behind the key

A perfect key policy does not help if the account itself is soft:

  • 2FA with an authenticator app, not SMS. SIM-swap attacks are routine and cheap against phone-based codes.
  • A unique password, stored in a password manager. Exchange credentials reused from an old forum breach remain a leading cause of account loss.
  • A withdrawal address allowlist, with the delay the exchange applies when a new address is added. If someone does get in, this is the control that keeps funds from leaving.
  • Anti-phishing code, if offered. Real exchange emails carry it; the convincing fake will not.
  • Read your active API keys once a quarter and delete every one you no longer recognise or need. Old keys from services you stopped using are the most commonly forgotten exposure on an exchange account.

If you think a key leaked

Revoke it on the exchange first — before investigating, before asking anyone what happened. Revocation is instant and free; reconstruction of what a key did while you deliberated is neither. Then check open orders, withdrawal history and address allowlist entries you did not create, rotate the account password, and re-issue what you still need as fresh keys.

What we can and cannot do with a key you connect

Stated plainly, because a rating platform asking for exchange access should have to say this:

  • We can read your trade history and balances to verify a record.
  • We cannot open, close or modify a position, and we cannot move funds — those permissions are refused at connection time, so we never hold a key that could.
  • You can revoke access from the exchange side at any moment, without telling us. Nothing in our system survives that revocation.

What a verified badge based on that access does and does not claim is set out in the Verification Guidelines, and how signal-channel accuracy is computed — no keys involved, only public posts replayed against price data — is on the Methodology page. Nothing here is financial advice.