Trading bot API key security: the rules that prevent disasters
An exchange API key is the bot's hands on your account. Configured carelessly, a leaked key can drain your funds in seconds; configured correctly, the worst a leak can do is place a few trades you can reverse. The difference is a handful of settings you choose before the bot ever runs. This is the most important page on the site to get right — the rules that keep an automated bot from becoming an automated robbery.
Rule 1 — trade-only permissions, never withdrawals
Every exchange lets you scope an API key. A trading bot needs exactly two things: read balances/orders, and place/cancel trades. It needs nothing else. Above all, never enable withdrawal permission.
A trade-only key with withdrawals disabled cannot move funds off the exchange, even if an attacker steals it. The funds stay put; you revoke the key and you're done. A key with withdrawal rights is a wire transfer waiting to happen.
Rule 2 — IP whitelisting
Most exchanges let you bind a key to specific IP addresses. Whitelist your VPS's IP and the key becomes useless from anywhere else — a stolen key can't even authenticate from an attacker's machine.
Rule 3 — store secrets out of code
Never hard-code keys in your script or commit them to git. Load them from environment variables or a secrets manager at runtime.
python · secrets.pyimport os
# load from env — never a literal string in code
key = os.environ['EXCHANGE_KEY']
secret = os.environ['EXCHANGE_SECRET']
# add .env and *.key to .gitignore so secrets never reach git
bash · gitignore# .gitignore
.env
*.key
config.local.json
Rule 4 — rotate and minimize scope
- Rotate keys periodically and immediately if you suspect exposure.
- One key per bot — so revoking one doesn't take down everything.
- Sub-accounts — if your exchange supports them, isolate the bot's capital from your main balance.
Rule 5 — understand the cloud-bot trust model
Platforms like 3Commas and Cryptohopper store your API keys server-side. That's a real, ongoing trust decision — their breach is your breach. If you use one, the trade-only + no-withdrawal rule matters more, not less. Self-hosting (e.g. Freqtrade) keeps keys on your own machine.
Security checklist
- Key scoped to read + trade only. Withdrawals OFF.
- IP-whitelisted to your server.
- Secrets in env vars or a vault — never in code or git.
- One key per bot; rotate on any suspicion.
- Sub-account isolation if available.
- For cloud bots, accept and minimize the custody-of-access risk.
Frequently asked questions
Should a trading bot's API key have withdrawal permission?
Never. A bot only needs permission to read balances/orders and place trades. Disabling withdrawals means that even if the key is stolen, an attacker cannot move funds off the exchange — the worst they can do is place a few reversible trades. This single setting prevents the worst outcome.
What is API key IP whitelisting?
It binds an API key to specific IP addresses, usually your server's. A whitelisted key cannot authenticate from any other machine, so a stolen key is useless to an attacker operating from a different IP. Enable it wherever your exchange supports it.
How should I store trading bot API keys?
Load them from environment variables or a secrets manager at runtime — never hard-code them in your script or commit them to git. Add .env and key files to .gitignore. Rotate keys periodically and immediately if you suspect exposure.
Are cloud trading bots safe with my API keys?
Cloud platforms store your keys server-side, so their security becomes your security and a breach on their side is a breach of your account access. If you use one, connect only trade-only keys with no withdrawal rights. Self-hosting keeps keys on your own machine and removes that third-party risk.