What does a trading bot API actually do?
An API (application programming interface) is just a defined way for your code to talk to the exchange without a human clicking buttons. The exchange exposes a fixed menu of actions, and your bot calls them.
In practice a bot touches four kinds of endpoints:
- Market data — order book, recent trades, candles, ticker prices.
- Account — balances, open positions, current leverage.
- Trading — place order, cancel order, modify order, query order status.
- Wallet — deposits and withdrawals (usually disabled on bot keys, and you should keep it that way).
That is the whole surface. A grid bot, a DCA bot, and a market maker all use the same handful of calls; they just differ in when and how often they hit them.
REST vs WebSocket API: which does what?
These are the two transports, and confusing them is the most common beginner mistake. REST is request-response: you ask, you get one answer, the connection closes. WebSocket is a single connection that stays open and pushes data to you as it changes.
The split most bots settle on:
- REST for actions you initiate — placing and cancelling orders, querying balances at startup, pulling historical candles.
- WebSocket for anything that changes constantly — live prices, order book updates, and fill notifications. You subscribe once and the exchange streams updates.
Why not poll prices over REST every second? Because it is slow, wasteful, and burns your rate limit. A WebSocket feed gives you order book changes in milliseconds and tells you the instant an order fills, without you asking. A latency-sensitive strategy like a market making bot or a crypto arbitrage bot is basically unworkable on REST polling alone.
| Aspect | REST API | WebSocket API |
|---|---|---|
| Direction | You ask, exchange answers | Exchange pushes to you |
| Connection | Opens and closes per request | Stays open |
| Best for | Placing orders, one-off queries | Live prices, order and fill updates |
| Latency | Higher (full round trip each call) | Lower (data arrives as it happens) |
| Rate-limit cost | Each call counts | Cheap once subscribed |
Most serious bots use both: WebSocket to watch the market and confirm fills, REST to send the actual orders. Some exchanges now also let you place orders over WebSocket, which shaves off a few milliseconds.
How does an order flow from bot to fill?
Here is the actual path, step by step, when your bot decides to buy.
- Build the request. Your bot assembles the order: symbol, side, type (market or limit), quantity, price, and a timestamp.
- Sign it. The request is signed with your secret key, usually an HMAC-SHA256 hash of the parameters. This proves the request came from you without sending the secret over the wire. Most exchanges also require a timestamp and reject requests that arrive outside a small window (often a few seconds) to block replay attacks.
- Send over REST. The signed request hits the order endpoint over HTTPS.
- Gateway checks. The exchange verifies the signature, checks your rate limit, and confirms you have the balance. Any failure returns an error code instead of an order.
- Matching engine. A valid order enters the order book. A market order matches against resting orders immediately; a limit order rests until price reaches it.
- Fill and confirmation. When it matches, the exchange returns a fill over REST and, if you are subscribed, pushes a fill message over your WebSocket almost instantly.
Round-trip time for the REST call is typically tens to a couple hundred milliseconds depending on your distance from the exchange servers. That gap is exactly why arbitrage and market-making shops pay for servers physically close to the exchange. For most retail strategies it does not matter; for a bot chasing a two-basis-point spread, it decides whether you win or lose. If you want the mechanics of keeping that connection alive, see running a bot 24/7.
Where do rate limits bite?
Rate limits are the number one thing that breaks a working bot in production. Every exchange caps how many requests you can send per window, and hitting the cap gets you throttled or temporarily banned.
Limits usually come in two flavours:
- Weight-based request limits. Each endpoint has a "weight," and you get a budget per minute. A simple ticker query might cost 1, while pulling a deep order book costs 20 or more. Budgets are commonly in the low thousands of weight per minute, tracked per IP or per key.
- Order rate limits. Separate caps on how many orders you can place or cancel per second and per day. Exceed them and new orders bounce with an error while queries still work.
Where it bites in practice: a grid bot that replaces dozens of orders on every tick, or a bot that polls balances in a tight loop. The fixes are boring but reliable — subscribe to WebSocket for anything live instead of polling, batch cancels where the API allows it, cache data that does not change often, and read the rate-limit headers the exchange returns so you can back off before you get banned. Never treat a rate-limit reject as "try again immediately"; that is how a soft throttle becomes a hard ban. When your bot runs on a VPS or home server that shares one IP with other tools, remember they all draw from the same limit.
What API key permissions should a bot have?
When you create an API key, the exchange lets you scope what it can do. Get this wrong and a leaked key drains your account; get it right and the damage from a leak is capped.
- Read — see balances and market data. Harmless on its own.
- Trade — place and cancel orders. Required for any bot that actually trades.
- Withdraw — move funds off the exchange. A bot almost never needs this. Leave it off.
Two more settings matter. IP whitelisting ties the key to your server's IP so a stolen key is useless from anywhere else — turn it on. And many exchanges let you disable withdrawals at the key level even if the account allows them. A copy-trading or signal bot that only needs to read positions should get a read-only key, nothing more. The full checklist lives in securing your bot API keys.
The rule of thumb: an API key can only do what you granted it, so grant the minimum. No legitimate bot strategy needs withdrawal rights.
How do CEX and DEX APIs differ?
Centralized exchanges (Binance, Coinbase, Kraken) give you the model above: REST plus WebSocket, an API key and secret, HMAC signing. You trust the exchange to custody funds and run the matching engine.
On-chain venues work differently. On a perp DEX like Hyperliquid or GMX, there is no username-and-password API key. Your bot signs each action with your wallet's private key, the same cryptographic key that controls your funds. Some perp DEXs run an off-chain order book with an exchange-style API for speed, then settle on-chain; others route everything through smart contracts, where every order costs gas and confirmation is tied to block times.
The trade-offs are real: on-chain means self-custody and no account to freeze, but also higher latency, gas costs, and a private key that must never touch a logged request. Hyperliquid, for instance, publishes a REST and WebSocket API that feels familiar to CEX developers while settling positions on its own chain — see the Hyperliquid bot ecosystem and the broader on-chain vs CEX comparison for how these choices play out.
Frequently asked questions
What is the difference between REST and WebSocket for trading bots?
REST is request-response: your bot asks once and gets one answer, ideal for placing orders and one-off queries. WebSocket keeps a connection open and streams live data like prices and fill notifications as they happen. Most bots use REST to send orders and WebSocket to watch the market and confirm fills.
Do I need a WebSocket connection to run a bot?
Not always. A slow strategy like a daily DCA bot runs fine on REST alone. But anything that reacts to price in real time, cares about latency, or needs instant fill confirmation should use WebSocket. Polling prices over REST is slower and burns through your rate limit far faster.
What causes API rate limit errors?
Sending too many requests in a short window. Exchanges cap requests by weight per minute and orders per second. Tight polling loops, grid bots replacing many orders per tick, and multiple bots sharing one IP are common culprits. The fix is using WebSocket for live data, caching, and backing off when the exchange signals you are near the limit.
Can a trading bot withdraw my funds through the API?
Only if you grant the key withdrawal permission, which almost no strategy needs. Create keys with read and trade rights only, leave withdraw off, and add IP whitelisting. Scoped that way, even a leaked key cannot move funds off the exchange, which is the single most important safeguard for any bot.
How fast can a bot place an order?
A REST order round-trip is typically tens to a couple hundred milliseconds, dominated by your network distance from the exchange servers. Professionals colocate near the exchange to cut this to single-digit milliseconds. For most retail strategies the difference is irrelevant; for arbitrage and market making it decides profitability.