# What your exchange API key lets a trading bot do

A bot can do what the exchange key allows, from where the key allows it. How Binance, OKX, Coinbase and Bybit split permissions, and what IP binding changes.

*https://cryptomarkets.tools/guides/what-your-api-key-lets-a-bot-do · background to Crypto Trading Bots*

**Answer:** A bot can do exactly what the exchange key allows, from wherever the key allows it, and the exchange sets both. Venues split permissions differently: OKX's trade permission includes funding transfers, Coinbase keeps transfer separate. IP binding is the lever that changes most: on Binance an unbound HMAC key can only read, OKX expires unbound trading keys after 14 idle days, and a key bound to a hosted bot's addresses works for anyone inside that vendor.

Connecting a hosted bot looks like a decision about the bot. It is a decision about a credential the
exchange issues, and everything the bot can do — trade, move money between accounts, withdraw —
was settled when you ticked the boxes on the exchange's key page. The bot's own security page
cannot widen that and cannot narrow it.

This page covers the mechanism across venues. The task of wiring one strategy to several exchanges
is in [how to place an order on several exchanges](https://cryptomarkets.tools/how-to/place-an-order-on-several-exchanges);
the history of one platform whose users' keys were exposed is on the [3Commas card](https://cryptomarkets.tools/tools/3commas)
and its [alternatives page](https://cryptomarkets.tools/alternatives/3commas).

## How it works

An exchange API key is four things, and only the first is the string you paste.

1. **A credential.** A key and a secret, or a key and a private key you generated yourself. Binance
   distinguishes the two: "System-generated API keys use HMAC symmetric encryption", while
   "self-generated API keys use Ed25519 or RSA asymmetric encryption", where you keep the private
   key and give Binance the public one. Binance's own API documentation now says plainly that "HMAC
   keys are deprecated".
2. **A permission set.** Read, trade, transfer, withdraw — named and bundled differently on each
   venue.
3. **A place it may be used from.** An IP allowlist, optional on some venues and a precondition for
   some permissions on others.
4. **A lifetime.** Some keys expire, and on some venues the rule depends on whether item 3 is set.

A hosted bot holds the first item and calls the exchange from its own servers. Items 2, 3 and 4
are enforced by the exchange on every request, whoever sends it.

## What each venue grants

### Binance: the IP restriction is a gate, for one kind of key

The key-creation FAQ, last updated 20 March 2025, is explicit: "Unrestricted-IP-Access HMAC API
Key(s) won't have any permission other than reading." To enable other permissions, it lists three
routes — "add IP access (IPv4 format) restrictions, use self-generated keys (such as Ed25519 or
RSA), or disable the default security controls."

Two consequences. An HMAC key that a bot can trade with is, by default, bound to the bot's
addresses. And the gate is specific to HMAC keys: a self-generated key is not held to it by that
sentence. Withdrawal is separate and stricter: "Adding IP access (IPv4 format) restrictions is
mandatory to enable withdrawal permission."

### OKX: three permissions, and Trade moves money

The v5 documentation names three permissions, any combination per key:

- **Read** — "Can request and view account info such as bills and order history".
- **Trade** — "Can place and cancel orders, funding transfer, make settings".
- **Withdraw** — "Can make withdrawals".

The middle line is the one to read twice. A trade-only key on OKX can move funds between your
accounts; it cannot send them off the exchange.

The IP rule here is about lifetime, not permission. A key binds up to 20 addresses, IPv4, IPv6 or
network segments, and "API keys that are not linked to an IP address and have `trade` or `withdraw`
permissions will expire after 14 days of inactivity." What counts as activity is narrow: only a call
to an endpoint "that requires API key authentication", and on a websocket "only operation of logging
in". Passing the key to a public endpoint does not keep it alive.

### Coinbase: view, trade and transfer, kept apart

Keys for the Advanced Trade API are created on the Coinbase Developer Platform, and every private
endpoint needs one of three scopes: `view`, `trade` or `transfer`. The scope table puts order entry,
edits, cancels and conversions under `trade`, and moving money under `transfer` — moving funds
between portfolios, scheduling and cancelling futures sweeps, allocating to an international
portfolio. The key-permissions endpoint describes `can_transfer` as "deposit/withdrawal
permissions", and the authentication page warns: "If someone obtains your api_secret with the
transfer permission, they will be able to send all the digital currency out of your account."

A key is also tied to a portfolio: the same endpoint returns the `portfolio_uuid` it belongs to, so a
key created for one portfolio sees that portfolio. The IP allowlist is "recommended but not
required", and nothing in the pages read here ties a permission or an expiry to it. The key must use
ECDSA: "Do NOT select Ed25519 as it is not supported by Coinbase App APIs."

### Bybit: permissions by product, and an expiry for unbound keys

The page read here is the endpoint for creating a sub-account key, and its parameter notes state
the rules. A key is read-only or read-write, with permission groups by product — contract trade, spot trade, options, wallet
transfers, convert, earn. Unbound keys expire: "No ip bound api key will be invalid after 90 days",
and "api key without IP bound will be invalid after 7 days once the account password is changed."
Those notes are on the sub-account endpoint; whether the same periods apply to every key created in
the web interface is not stated there.

## Why IP binding changes what a hosted bot can do

**A hosted bot calls from the vendor's addresses, so binding means binding to the vendor.** To bind
the key you enter the IP addresses the vendor publishes. From then on the key works from those
addresses and nowhere else. Bot cards here record the instruction in its several forms:
[3Commas](https://cryptomarkets.tools/tools/3commas) asks for its platform's addresses to be whitelisted wherever the exchange
allows it, [Altrady](https://cryptomarkets.tools/tools/altrady) documents exchange-side whitelisting, and the routed mode of
[Tealstreet](https://cryptomarkets.tools/tools/tealstreet) needs its addresses allowlisted at the exchange to work at all.

**That protects against a leak outside the vendor, not against a problem inside it.** A stolen key
bound to the vendor's addresses is useless from an attacker's own machine. It is fully usable from
the vendor's infrastructure, which every one of that vendor's customers shares. Binding narrows who
can use the key to the vendor and whoever controls the vendor's servers; it does not narrow it to
you.

**Without binding, the venue decides what the bot can do.** On Binance an unbound HMAC key is
read-only, so a hosted bot that publishes no addresses can trade only on a self-generated key or
with the default controls switched off. On OKX an unbound trading key expires after 14 days without
an authenticated call, so a bot paused for a fortnight comes back to a dead key. On a Bybit key
created through the sub-account endpoint, the clock is 90 days.

**On your own machine the problem inverts.** A self-hosted bot on a home connection has an address
that changes, and a key bound to yesterday's address fails today. The usual answer is a fixed egress
address — a server, not a laptop — which is a cost the self-hosted path carries and the hosted one
moves to the vendor.

**"Trade-only" is not a portable instruction.** A bot vendor that asks for trade permission with
withdrawals off is asking for different things on different venues: on OKX that key can still make
funding transfers between your accounts; on Coinbase the equivalent moves sit under `transfer` and a
`trade` key cannot make them.

## What it costs

Nothing in fees. Every venue above issues keys, permissions and allowlists free. The costs are
operational:

- **Renewal.** An unbound OKX trading key lapses after 14 idle days; a Bybit sub-account key
  without an IP lapses after 90 days, or 7 after a password change. Somebody has to notice.
- **Address changes.** A key bound to a vendor's addresses breaks when the vendor changes them, and
  a key bound to your server breaks when you move it. Both fail closed, which is the point, and both
  fail at an hour nobody chose.
- **Re-issuing.** A key you suspect is exposed cannot be fixed, only replaced — at every venue the
  bot was connected to.

## What you can do about it

**Set permissions at the exchange as if the bot's settings did not exist.** Read-only for anything
that only reads — portfolio trackers, journals, dashboards. Trade for a bot that trades. Withdraw or
transfer for nothing that runs unattended.

**Read the venue's definition of trade before you accept "trade-only".** On OKX it includes funding
transfers; on Coinbase it does not. If a vendor's connection guide gives one instruction for every
venue, translate it per venue.

**Bind every trading key to an address when the venue allows it.** For a hosted bot, use the
addresses the vendor publishes and note where it publishes them, so you can check them when it
changes. For a self-hosted bot, run it from a fixed address.

**Check what a key can actually do, from the exchange's side.** Coinbase's key-permissions endpoint
returns `can_view`, `can_trade`, `can_transfer` and the portfolio the key belongs to. OKX's
`GET /api/v5/account/config` returns `perm` for the requesting key and `ip`, which is an empty
string when no address is bound. Call them with the key you are about to hand over, not with the
one you meant to create.

**One key per bot, and a sub-account where the venue offers one.** A key shared between two tools
cannot be revoked from one of them. A sub-account caps what any one key can reach to what is in it.

**Revoke at the exchange when you stop.** Deleting the bot account, or the bot vendor closing a
platform, leaves the key alive at the venue until you delete it there.

## Tools this bears on

- [3Commas](https://cryptomarkets.tools/tools/3commas.md) — Hosted DCA, grid and signal bots on nine exchanges, relaunched in 2026 with WunderTrading.
- [Altrady](https://cryptomarkets.tools/tools/altrady.md) — Multi-exchange trading workspace — smart orders, scanners, bots and a journal.
- [Tealstreet](https://cryptomarkets.tools/tools/tealstreet.md) — One free front-end over twenty-odd venues, with your keys never leaving your machine.
- [WunderTrading](https://cryptomarkets.tools/tools/wundertrading.md) — TradingView-alert execution, grid and DCA bots, and a REST API and MCP server on top.

## FAQ

### Can a trading bot withdraw my funds?

Only if the key you gave it carries a withdrawal or transfer permission. Binance makes an IP restriction mandatory before withdrawal can be enabled; OKX lists Withdraw as its own permission; Coinbase calls it transfer and describes it as deposit and withdrawal. Note that OKX's Trade permission itself includes funding transfers, so trade-only does not mean the same thing everywhere.

### Why can't I enable trading on my Binance API key?

Binance's key-creation FAQ, last updated 20 March 2025, states that an HMAC key with unrestricted IP access will not have any permission other than reading. To enable more, it lists three routes: add IPv4 restrictions, use a self-generated Ed25519 or RSA key, or disable the default security controls.

### Why did my OKX API key stop working?

If it had trade or withdraw permission and no IP address bound to it, OKX's documentation says it expires after 14 days of inactivity. Only calls to authenticated endpoints count as use, and on a websocket only the login does, so a bot that sat idle for two weeks loses its key.

### Does whitelisting a hosted bot's IP addresses make my key safe?

It makes the key useless from anywhere else, which stops most theft. It does not restrict use from inside the bot vendor's infrastructure, which those addresses belong to and which every customer of that vendor shares. The binding protects against a leak outside the vendor, not against a compromise within it.

## Sources

1. [How to create API keys on Binance](https://www.binance.com/en/support/faq/how-to-create-api-keys-on-binance-360002502072) — Binance, 2025-03-20
2. [API Key Types (faqs/api_key_types.md)](https://github.com/binance/binance-spot-api-docs/blob/master/faqs/api_key_types.md) — Binance, on GitHub, read 2026-10-23
3. [API v5 documentation — API key permissions and API key security](https://www.okx.com/docs-v5/en/) — OKX, read 2026-10-23
4. [Coinbase App API key authentication](https://docs.cdp.coinbase.com/coinbase-app/authentication-authorization/api-key-authentication) — Coinbase, read 2026-10-23
5. [Advanced Trade scope and permissions](https://docs.cdp.coinbase.com/coinbase-app/advanced-trade-apis/rest-scopes) — Coinbase, read 2026-10-23
6. [Get API Key Permissions (GET /api/v3/brokerage/key_permissions)](https://docs.cdp.coinbase.com/api-reference/advanced-trade-api/rest-api/data-api/get-api-key-permissions) — Coinbase, read 2026-10-23
7. [V5 API — Create Sub UID API Key (POST /v5/user/create-sub-api)](https://bybit-exchange.github.io/docs/v5/user/create-subuid-apikey) — Bybit, read 2026-10-23

*Last updated 2026-10-23. A reference page, corrected in place — not a dated post.*