What is a trading API? Keys, REST and WebSocket explained

What an exchange or broker API is

API stands for application programming interface — a published contract describing exactly how one program can ask another to do something. An exchange API (Binance, Coinbase, Kraken) or a broker API (for stocks and futures) is that contract for the trading venue: a list of endpoints with defined inputs and outputs. Where you, as a human, log into the website and click "buy", your code sends a request to an endpoint like /order with the symbol, side, quantity and price, and the exchange responds with the order's status. The API is simply the machine-readable version of everything the website lets you do, exposed so that software can do it automatically and far faster.

REST vs WebSocket

Trading APIs come in two flavours, and a real bot usually uses both. REST is request-response: your code makes one call, the server sends one answer, the connection closes. It is perfect for actions — place an order, cancel an order, fetch your balance — because each is a discrete, confirmable event. WebSocket is a persistent, two-way connection that the server pushes data down continuously without you asking again. It is built for live data: streaming prices, order-book changes and your own order fills the instant they happen. The typical pattern is to watch the market over WebSocket and act on it over REST.

• Use REST to place and cancel orders, read balances, and query historical candles for backtesting.
• Use WebSocket for real-time price feeds and fill notifications, where polling REST repeatedly would be slow and would burn your rate limit.

API keys and permissions

Because an API request can move real money, the exchange must know it is genuinely you. That is what an API key is for: a pair of long random strings — a public key and a private secret — that you generate in your account settings. The key identifies the request; the secret is used to cryptographically sign it so it cannot be forged or replayed. Crucially, every key is created with a set of permissions that limit what it can do. The standard scopes are:

1. Read — view balances, positions and market data. Harmless on its own.
2. Trade — place and cancel orders. Required for a live bot, and the only write permission most bots ever need.
3. Withdraw — move funds off the exchange. A bot should never have this.

Most venues also let you bind a key to an IP whitelist, so it only works from your server's address. Combined with minimal permissions, this turns a leaked key from a catastrophe into a non-event. Our API key security for bots guide goes deeper on hardening.

Why you never enable withdraw

This is not paranoia; leaked keys are one of the most common ways automated traders lose funds, usually because a secret was accidentally pasted into a public repository or a chat. Scoping the key to read and trade only means the worst case is contained. When you later connect a bot to the Binance API, the very first step is generating a key with withdraw left off.

Rate limits

Exchanges protect their infrastructure with rate limits: a cap on how many requests you may send per second or per minute, often counted as weighted "request units" where heavier calls cost more. Exceed the limit and the API starts returning 429 Too Many Requests errors, and repeated abuse can get your key temporarily banned. A well-built bot respects these by batching requests, preferring a single WebSocket stream over hammering REST in a loop, and backing off when it sees a 429. Reading historical data for a backtest is the easiest way to blow your limit, so good libraries page through it politely with delays.

Libraries like ccxt

You rarely talk to a raw API by hand. Libraries wrap the endpoints, signing and connection details into clean function calls. The best known in crypto is ccxt, which exposes a single unified interface across more than a hundred exchanges, so the same code works whether you trade on Binance or Bybit. Here is a minimal, read-only example that fetches a price — note the key and secret are pulled from the environment, never hard-coded:

python · fetch_price.pyimport os, ccxt

exchange = ccxt.binance({
    'apiKey': os.environ['BINANCE_KEY'],   # from env, not the file
    'secret': os.environ['BINANCE_SECRET'],
    'enableRateLimit': True,            # auto-throttle to stay under limits
})

ticker = exchange.fetch_ticker('BTC/USDT')  # a REST request
print(ticker['last'])

That single call is a REST request under the hood; switching to exchange.watch_ticker in ccxt's pro variant would stream the same data over WebSocket instead.

Security risks of leaked keys

The convenience of an API is also its danger: the key is a credential that does whatever its permissions allow, with no further confirmation. Treat it like a password to a vault. Store keys in environment variables or a secrets manager, never in source code, and add the file holding them to .gitignore so they cannot be committed. Use IP whitelisting, grant the minimum permissions, rotate keys periodically, and revoke any key the instant you suspect it has been seen by anyone. If a key with only read and trade rights leaks, you can revoke it and reset before real damage is done — which is the entire reason for scoping it that way in the first place.

Frequently asked questions