Trade-Only API Keys: Why Your Bot Can't Withdraw Your Funds
An API key isn't a password — it's a scoped credential, and trade and withdraw are separate permissions on every exchange. This piece covers what a trade-only key actually allows, how the restriction gets enforced, and how to check your permissions screen before connecting.
An API key isn't a password. It's a scoped credential — a set of specific permissions an exchange grants to a connected app, and those permissions can include some account actions while excluding others entirely. A trade-only API key is scoped to exclude withdrawal: it can place orders, check balances, and pull trade history, but the exchange itself blocks any withdrawal attempt made through it, regardless of what the connected app requests.
That distinction answers the question this comes down to in every version it gets asked: can a bot move my funds anywhere? With a correctly scoped key, no — not because the bot chooses not to, but because the exchange won't let it.
At a glance
- Trade access covers placing, modifying, and canceling orders, plus viewing balances and trade history
- Withdraw access covers moving funds off the exchange entirely — a separate permission, off by default on a correctly scoped key
- The exchange enforces the split, not the connected app — a withdrawal request made through a trade-only key gets refused at the exchange's end
- Keys submitted with withdrawal permission already enabled are rejected automatically on connection, as a backstop
- The same trade/withdraw separation applies across every supported exchange — the toggle names differ, the split doesn't
What "trade" access actually covers
A trading bot needs to see account balances, read trade history, and place, adjust, or cancel orders — that's the complete list of what automated trading requires. Reading access surfaces what's in the account and what's already happened; trading access lets the bot act on it. Neither one touches where the funds physically sit.
What "withdraw" access means, and why it's excluded
Withdrawal is a separate permission covering the transfer of funds off the exchange to another wallet or address. It has nothing to do with trading — an exchange could let an app trade without ever granting it the ability to move funds out, and that's exactly the scope a trade-only key represents.
This follows a standard security principle: grant only the access a task actually requires, and nothing more. A bot's job is placing and managing orders. It never needs to move funds anywhere, so there's no legitimate case for requesting that permission in the first place — the scope isn't reduced as a courtesy, it's just never asked for.
How the restriction actually gets enforced
The trade/withdraw split isn't a promise the connected app makes — it's a setting the exchange controls. When an API key is generated, withdrawal permission has its own toggle, separate from trading and balance access, and it's typically off by default. If a request comes in through a key that doesn't have withdrawal enabled, the exchange itself refuses it. The connected app doesn't need to be trusted not to try; the permission to succeed simply isn't there.
As a second layer on top of that, keys submitted with withdrawal access already switched on get rejected automatically at the connection step, before the bot can use them for anything. A correctly scoped key is the only kind that connects in the first place.
Setting it up correctly: a Binance example
On Binance, generating an API key surfaces a permissions screen with separate toggles, including Enable Reading, Enable Spot & Margin Trading, and Enable Withdrawals. A key meant for bot trading needs the first two switched on and the third left exactly where it starts — off.
Binance also ties an API key without an IP whitelist to a 90-day expiry on its trading permission. Add the relevant IP addresses to the key's allowlist, and that expiry goes away; skip it, and the trading permission needs re-confirming on Binance's end every 90 days or it lapses automatically. How IP whitelisting works covers that mechanism in more depth.
Other exchanges label these toggles differently, and the exact screen looks different everywhere, but the underlying split holds across all of them: a reading permission, a trading permission, and a withdrawal permission, controlled separately. Setting up a bot connection means switching on the first two and leaving the third alone.
Checking takes under a minute — do it on every connection, not just the first one. Exchanges occasionally redesign their permissions screens, and a setting that defaulted correctly last year isn't guaranteed to default the same way after an update.
The layers stacked on top
Trade-only scoping closes off the biggest risk — funds physically leaving the exchange — but it isn't the only protection in place. IP whitelisting restricts which servers can actually use a key, even a correctly scoped one. Countertrade protection watches for a specific manipulation pattern where a compromised key gets used to move a thin market's price rather than withdraw from it directly. Most platforms also block the same API key from being added to more than one account, closing off a different kind of misuse. None of these replace the trade/withdraw split — they cover what it doesn't.
Permission comparison
| Permission | What it allows | Needed for bot trading? |
|---|---|---|
| Read (balance & history) | View balances, open orders, and past trades | Yes |
| Trade | Place, modify, and cancel orders | Yes |
| Withdraw | Move funds to an external wallet or address | No — excluded by design |
Common mistakes
Assuming API access is all-or-nothing. It isn't. Reading, trading, and withdrawal are controlled separately on every major exchange, and a key can be scoped to any combination of them.
Leaving withdrawal on out of habit. Someone setting up several integrations at once can end up copying permission settings from an unrelated tool without checking each toggle individually.
Skipping IP whitelisting, then losing trading access unexpectedly. On exchanges that tie unrestricted keys to an expiry window, this shows up as a bot that mysteriously stops trading weeks after setup — not a bug, just a lapsed permission.
Reusing one API key across multiple tools or accounts. Several exchanges block this outright, and even where they don't, one key touching multiple systems multiplies the exposure if any single one of them is compromised.
FAQ
Can a trading bot withdraw my funds? No, if the API key is scoped correctly. Withdrawal is a separate permission from trading, off by default, and a key submitted with it enabled gets rejected on connection rather than allowed through.
What happens if I accidentally enable withdrawal permission on my API key? The connection gets refused. Keys with withdrawal access enabled are automatically rejected rather than connected, so the fix is regenerating the key with that permission switched off.
Does a trade-only API key mean my funds carry zero risk? It closes off the biggest risk — funds leaving the exchange — but a compromised key can still be misused within its trading scope, for instance to manipulate a thin market. That's what additional layers like IP whitelisting and countertrade protection exist to cover; trade-only scoping and those other layers work together, not as a single fix.
Is the trade/withdraw split the same on every exchange? The underlying separation is standard across major exchanges — it's a feature of how exchange-side API permissions work, not something specific to any one trading platform. The toggle names and screens differ; the split itself doesn't.
Do I need to configure anything extra to make my key trade-only? Just leave withdrawal switched off — it's off by default on most exchanges. As a backstop, a key generated with it enabled won't connect successfully anyway.
