Skip to main content
API key security is the single most important operational topic for an unCoded operator. Your funds live on the exchange; the API keys are what authorize the bot to trade them. Get the permissions right, scope them tightly, and rotate them periodically — and the worst-case if a key leaks is limited.

​
The single most important rule

NEVER ENABLE WITHDRAWAL PERMISSION ON YOUR TRADING API KEYS.This is non-negotiable. unCoded never needs to withdraw funds from your exchange. The bot places buy orders, sell orders, and queries your balance — none of which require withdrawal permission.If a key with withdrawal permission leaks, an attacker can drain your account. If a key without withdrawal permission leaks, the worst they can do is trade your funds — which they can’t get out.This single permission decision is the difference between “key leak is a recoverable incident” and “key leak is catastrophic.”

​
The four mandatory permission settings (universal across venues)

Every exchange’s API key creation form has a permissions section. The universal rule, valid across all 17 supported venues:
Required for the bot to query market data, your account balance, your open orders, and your trade history. Without read permission, the bot cannot function.Risk if leaked: an attacker can see your trade history and balances. Inconvenient privacy issue, but not financially catastrophic.
Required for the bot to place buy and sell orders. The core operational permission.Risk if leaked: an attacker can trade your funds — buy at bad prices, sell at bad prices, churn your balance. They cannot withdraw your funds (assuming you correctly disabled withdrawals). The financial damage is bounded by what they can lose to fees and bad trades within your balance.
The single most critical setting. If checked, the API key can withdraw funds from your account. If a key with this permission leaks, your funds are at immediate risk.Every venue’s API key form has this off by default. Leave it off. Verify you have not accidentally enabled it.The unCoded bot does not need this permission for any of its functions. There is no scenario where you should ever enable it.
The pre-built modes are spot-only. If you enable margin or futures permissions, you’re widening the API key’s authority beyond what the bot uses.Operator policy: enable only if you’ve explicitly chosen a mode that uses these (rare). For the standard 9 pre-built modes, keep these disabled.
Some venues have an “internal transfer” or “universal transfer” permission for moving funds between sub-accounts or wallets within the venue. The bot does not need this.Even though internal transfers don’t leave the venue, they are a permission the bot doesn’t require. Operator-policy: disable.

​
IP allowlisting — a strong second factor

IP allowlist your API keys to your VPS’s static IP. This means even a leaked key cannot be used from any other machine.This is a transparent operator improvement: it adds a strong second factor (the requesting source IP must match) without affecting normal operation.
Most venues let you restrict an API key to specific source IPs. When the venue receives a signed request using that key, it checks whether the source IP is on the allowlist. Mismatch → request rejected with -2015 (Binance) or equivalent.With IP allowlisting active, an attacker who has stolen your API key still needs to be on an allowlisted IP to use it. They typically aren’t.
From the VPS itself:
curl -s https://api.ipify.org
The output is your VPS’s public IP. Paste this into the venue’s allowlist field.Make sure your VPS has a static IP. Most VPS providers (Netcup, Hetzner, AWS Lightsail, etc.) assign a static IP by default. If yours assigns a dynamic IP, you’ll need to either upgrade to a static IP or accept that your allowlist will need updating after every IP change (annoying).
After saving an allowlist change at the venue, wait 30–60 seconds before testing. Most venues’ API gateways propagate the change asynchronously, and a test immediately after save may fail until propagation completes.If your test fails after a save, wait a minute and try again before assuming something else is wrong.
Any time your VPS gets a new IP (provider migration, IPv6 transition, host swap), update the allowlist at every venue you trade on. The bot will fail to trade until the allowlist matches the actual source IP.Build this into your operational runbook: “after VPS IP change, update allowlist at every venue, then test connection.”The Dashboard’s connection-state panel will show every venue as disconnected until the allowlists are updated.
Some venues don’t support IP allowlisting on all account tiers. If your venue doesn’t support it:
  • The API key is more sensitive — protect it more carefully.
  • Rotate more frequently (monthly instead of quarterly).
  • Watch the venue’s API-key audit log more closely for anomalies.
For most major venues (Binance, Bybit, OKX, Kraken, Coinbase, Bitvavo), IP allowlisting is available. Use it.

​
The pre-flight checklist for every API key

Before you paste a new API key into the unCoded Dashboard, run through this checklist. If any item fails, fix it before proceeding.
1

Verify withdrawal is disabled

Open the venue’s API key settings page. Confirm “Enable Withdrawals” (or equivalent) is unchecked. If checked, uncheck it and save.This is the single most important verification. Do not skip.
2

Verify spot trading is enabled

Confirm “Enable Spot Trading” (or equivalent) is checked. Without this, the bot can’t place orders. With it, the bot can trade.
3

Verify margin / futures / derivatives is disabled

Confirm these are unchecked unless you’ve specifically chosen a mode that requires them. For the 9 pre-built modes, all should be off.
4

Verify IP allowlist is set

Confirm the IP allowlist contains your VPS’s static IP and only your VPS’s static IP. Multiple IPs in the allowlist (e.g., your laptop + VPS) is a smell — your laptop should not be authenticating to the API.
5

Verify the key has a descriptive label

Name the key something like unCoded-prod-binance-main so you can identify it later. Multi-key operators benefit hugely from clear labels — unCoded-test-bybit-2026q1 is clearer than My API Key 3.
6

Confirm the secret is saved in your password manager

Most venues show the secret only once at creation. Paste it into your password manager immediately. If you close the page without saving the secret, you have to revoke and recreate the key.
7

Test the key with a no-op call

The Dashboard’s “Test Connection” button issues a no-op authenticated call against the venue and verifies signing works. Run this before allocating any real strategy. If it succeeds, the key is wired correctly.

​
Rotation cadence

Rotate immediately if any of:
  • Your VPS was compromised, restored from backup, or migrated.
  • You logged into the venue from an unfamiliar device.
  • You see unfamiliar API key activity in the venue’s audit log.
  • The venue notifies you of a security incident.
  • You shared the API key (even briefly, even with someone trusted, even via “secure” chat) — once shared, it’s not secret anymore.
  • A team member with access has left, been let go, or had their device compromised.
  • You suspect anything weird, even if you can’t articulate why.
Better to over-rotate than to under-rotate.
Once a year, audit all your active API keys across all venues:
  • Are there any keys you no longer use? Revoke.
  • Are the permissions still correct? Tighten if anything has loosened.
  • Are the IP allowlists current? Update if your VPS IPs have changed.
  • Are the labels still descriptive? Re-label if you’ve forgotten what they’re for.
The annual audit catches keys that drifted out of correct configuration over the year.
Keep a personal inventory of every API key:
VenueLabelCreatedLast rotatedPermissionsIP allowlist
BinanceunCoded-prod-binance-main2026-01-152026-04-15Spot, Read203.0.113.45
Update on every rotation. Stored in your password manager alongside the secrets.The inventory is what lets you answer “what keys exist?” without trying to guess. Especially valuable for multi-venue operators.

​
What an attacker can do with each level of compromise

Understanding the threat model helps calibrate your response to each scenario.
An attacker has a read-only API key (no trading, no withdrawals).What they can do: see your balance, see your open orders, see your trade history.What they cannot do: trade your funds, withdraw your funds, change your account settings.Severity: privacy leak. Inconvenient but not financially damaging. Rotate the key.
An attacker has a spot trading API key with withdrawal disabled.What they can do: place buy and sell orders against your balance. They could deliberately churn your account to bleed fees, or buy a thinly-traded asset at a high price to manipulate the market.What they cannot do: withdraw your funds. The damage is bounded by what they can lose within your balance.Severity: financial risk, but bounded. Rotate the key immediately. If IP allowlisting was active and they’re not on the allowlist, they couldn’t even use the key. Watch your account for unauthorized trading; assess damage.This is why the no-withdrawal rule matters. With withdrawals disabled, even a leaked active-trading key is a recoverable incident.
An attacker has a spot trading API key with withdrawal enabled.What they can do: drain your account.What they cannot do: nothing — they have full access.Severity: catastrophic. Funds may be irrecoverable.This is why you never enable withdrawals. There is no operational benefit and the downside is total loss.
An attacker has your account login.What they can do: log into the venue and do anything you can do — including changing API key permissions, withdrawing, transferring, etc.What they cannot do: bypass 2FA (if enabled).Severity: catastrophic if 2FA is missing or weak. Manageable if 2FA is strong (authenticator app, hardware key).Mitigation: use 2FA on every venue account, prefer authenticator apps over SMS, prefer hardware keys when supported.

​
Layered defense — multiple weak factors > one strong factor

The right mental model: stack multiple weaker layers rather than relying on one strong layer. Each layer adds cost to the attacker without adding meaningful cost to you.

Layer 1: Permission scoping

No withdrawals. No margin/futures unless needed. Spot only. Limits the blast radius of any compromise.

Layer 2: IP allowlisting

Even with a leaked key, the attacker has to be on your VPS’s IP. Unlikely without also compromising your VPS.

Layer 3: 2FA on the venue account

Protects against scenarios where your account password leaks but the API key doesn’t (or vice versa).

Layer 4: Secret hygiene

Keys in password manager only, never in plaintext, never shared via chat or email.

Layer 5: Periodic rotation

Quarterly rotation limits the window during which an undetected leak can be exploited.

Layer 6: Audit log review

Most venues offer an API-key audit log. Review monthly for unusual access patterns.

​
Common mistakes operators make

No. Withdrawals are never needed by the bot. “Just in case” is the rationalization that leads to catastrophic loss.If you ever genuinely need to withdraw, do it manually via the venue’s UI with full 2FA, then disable the API permission again. Don’t enable it permanently.
Even a secure VPS can be compromised. IP allowlisting is a defense-in-depth measure that costs nothing operationally and provides real protection.If your venue supports it, use it. Period.
Git repos leak — through forks, through stale backups, through accidental publication. API secrets in Git are a well-known source of credential compromise.Use environment variables, secret managers, or encrypted env files. Never commit secrets to source control.
Even a read-only key is a credential. Share it only if you trust the recipient with full visibility into your trade history and account size.For partner visibility, the better pattern is to add them to your Dashboard’s viewer role — they see panels but have no API access.
One key per bot per venue. If you run multiple TradingBot containers (one per exchange, or sub-account separation), each gets its own dedicated API key.Why: makes incident response easier (you can revoke one without affecting the others), makes rate limit accounting clearer, makes audit logs more useful.
Account 2FA and API key security are separate layers protecting separate things. Skipping account 2FA leaves a gaping hole regardless of API security.Use 2FA on every account. Authenticator app at minimum, hardware key where supported.
Keys you’ve forgotten about are keys you can’t audit. Even without an incident, periodic rotation forces an inventory check and confirms the key is still doing what you intended.Quarterly rotation. No exceptions.
The bot is what uses the API key, not you. The bot lives on one VPS with one IP. Logins from other locations should go through the venue’s web interface (with 2FA), not through the API key.Set the IP allowlist to your VPS only. Always.

​
When something goes wrong

  1. Revoke the leaked key immediately at the venue.
  2. Generate a new key with correct permissions.
  3. Update the Dashboard with new credentials.
  4. Restart the affected TradingBot container.
  5. Verify the bot resumes trading normally.
  6. Review the venue’s API audit log for the leak window — was the key used by the attacker? What did they do?
  7. Document the incident in your operator log: when, how, what was the impact.
  8. Review your security posture — was 2FA on? Was withdrawal disabled? Was IP allowlist active? Tighten any layer that wasn’t.
Common causes, in order of frequency:
  1. IP allowlist propagation delay. Wait 30–60 seconds and retry.
  2. IP allowlist mismatch. Verify your VPS’s actual public IP matches what’s on the allowlist.
  3. Wrong permissions. Verify spot trading is enabled.
  4. Wrong secret pasted. Re-paste the secret, watching for trailing whitespace.
  5. Clock drift. Verify your VPS’s NTP sync; rejection codes related to timestamps usually indicate clock skew.
The Dashboard’s logs and the venue’s response code (e.g., Binance -2015, Bybit 10003) usually point at the cause.
Verify in this order:
  1. Kill switch on?
  2. Exchange-side outage?
  3. Rate limit?
  4. Min-notional rejection?
  5. Insufficient balance?
  6. API key still active at the venue?
The Dashboard’s logs are your primary source. Almost every “the bot stopped trading” issue surfaces a clear log message explaining why.

​
Best practices

  • ✅ NEVER ENABLE WITHDRAWAL. This rule has no exceptions.
  • ✅ Always use IP allowlisting when the venue supports it.
  • ✅ 2FA on every venue account — authenticator app minimum, hardware key where supported.
  • ✅ Save secrets in a password manager only — never plaintext, never Git, never email or chat.
  • ✅ Quarterly rotation cadence — even without incidents.
  • ✅ One key per bot per venue — clear blast radius, clear audit trail.
  • ✅ Descriptive labels — unCoded-prod-binance-main not My API Key.
  • ✅ Pre-flight checklist before each new key — withdrawal off, spot on, IP set, label clear.
  • ✅ Annual full inventory audit — list all keys, permissions, IPs, last rotation.
  • ✅ Review the venue’s API audit log monthly — catch anomalies before they’re catastrophic.
  • ✅ Watch for changes in your VPS IP — update allowlists immediately if the IP changes.
  • ✅ Document your security posture in an operator runbook so you can re-verify quickly.

​
What’s next

Exchanges Overview

Pick your venue with the right context.

Binance Setup

Step-by-step Binance setup with all security details.

Bybit Setup

Bybit-specific permission walkthrough.

OKX Setup

Including OKX’s passphrase requirement.

Coinbase Setup

Coinbase Advanced for US operators.

Troubleshooting

Every common API key error and recovery procedure.
Last modified on May 3, 2026