SHARKRULE / Learn

Trading bot API key security: permissions, IP limits and revocation

An exchange API key gives software specific powers over your exchange account. Before connecting a trading bot, decide which powers it needs, how much it may trade and how you will stop it. A connection that works is only the beginning of that check.

SharkRule · Reviewed

Exchange account access is different from a wallet connection

A custodial exchange holds assets for your account. An API connection lets software read information or submit permitted instructions to that exchange. It does not require the recovery phrase of a self-custody wallet. If a service asks for a wallet seed phrase to connect a Binance or Kraken trading account, stop and verify what it is actually requesting.

Write down the exchange, account, market type and service name before creating anything. A Spot connection and a derivatives connection can have different permissions and consequences. This guide concerns operational access, not choosing an asset or a trading strategy.

Choose permissions by task

Treat permission settings as a list of actions you are authorizing. For a first connection check, account-reading access may be enough. Automated trading needs additional permissions, and the exact names vary by exchange.

A minimum-permission review
PurposePermission to investigateQuestion to resolve
Display balancesAccount read accessWhich account data becomes visible?
Place and manage ordersTrading plus required order queriesCan the service identify fills and cancel remaining orders?
Move funds outWithdrawal or transfer accessWhy would an order-only workflow need this?
Observe public pricesPublic market-data APICan this work without an account key?

Disabling withdrawals does not remove trading risk

An order-only key can still expose an account to unwanted purchases, repeated trades, fees or sales at poor prices. Withdrawal restrictions therefore protect one route of access; they do not make a trading service harmless. Consider the maximum value a malfunctioning rule could commit, including orders already waiting to fill.

For example, an invented rule budget of 200 units with 120 already reserved by open orders has only 80 units uncommitted before fees and any safety buffer. A screen showing 200 as the configured budget is not evidence that another 200-unit order fits. This is an accounting example, not a recommended allocation.

Review the service and the key before connecting

Use a different key for each service so you can identify and revoke one connection without guessing which other tools use it. When an exchange supports an IP allowlist, obtain the provider’s documented outgoing server addresses. Your laptop’s address is generally irrelevant when orders originate on a hosted service.

Ask where credentials are stored, who can access them, how they are redacted from logs and how deletion works. Keep secrets out of support tickets, screenshots, source repositories and browser analytics. A named security feature is less useful than a clear explanation of its scope.

  1. Confirm the exact service domain and exchange account.
  2. Document the required account-reading and trading actions.
  3. Leave withdrawal and unrelated funding powers disabled for an order-only workflow.
  4. Apply supported IP restrictions and review key expiry where available.
  5. Check the connection without placing a live order; then test the intended controls separately.

Prepare a stop procedure before enabling a rule

Stopping a bot, canceling its orders and revoking its credential are separate operations. A stopped worker may leave accepted orders at the exchange. A canceled order may already have partial fills. Review open orders and trade history directly at the exchange after a stop; do not assume the bot dashboard tells the whole story.

If credentials may have leaked, revoke the affected access promptly through the exchange and contact its support when needed. Preserve an incident record containing timestamps, key labels and order identifiers, without copying the secret. Then reconcile activity before reconnecting. A fresh key will not correct an unresolved order or unsafe rule.

Keep a small connection record

Record the service name, key label, creation date, approved permissions, allowed server addresses, review date and revocation location. Store the secret separately in an appropriate protected system. Revisit that record when the provider changes infrastructure, someone leaves your team or a tool is no longer used.

The practical finish line is simple: you can explain what this connection may do, find its outstanding orders and remove its access. If any of those answers is missing, resolve it before authorizing unattended trading.

Frequently asked questions

Is a read-only API key risk-free?

It should not authorize trading if correctly restricted, but it can expose sensitive balances and activity. Review the exact exchange permissions and the provider’s data handling.

Can a bot trade while withdrawals are disabled?

Yes, if the exchange key has the necessary trading permissions. Trading itself can still cause losses.

Does deleting the API key cancel orders?

Do not rely on it. Reconcile open orders and fills directly at the exchange and use its supported cancellation controls.

Official documentation and references

Prepared with AI assistance from the linked official documentation. Examples are hypothetical; no live account tests or return comparisons were performed.