Exchange API Integration: REST, WebSockets, Authentication and Security

A trading bot reads prices and places orders through exchange APIs. This guide explains the roles of REST and WebSockets, request signing, rate limits and key security.

REST versus WebSockets

REST uses request and response, making it suitable for actions such as placing or canceling an order and querying balances. WebSockets maintain a connection for server-pushed updates, such as price, order-book and private order-status changes.

The workflow presented here uses WebSockets for market data and REST for order submission. Prices arrive through the stream, signals are evaluated, and a decision triggers a REST order. Fast-response methods such as scalping depend more heavily on streaming data.

Authentication and signing

Market data is often public, but orders and balances require private authentication. The guide describes a common model using an API key and secret key with an HMAC-SHA256 signature.

1. Include a current timestamp. The original guide uses roughly ±5 seconds from server time as its example tolerance; clock mismatch can cause rejection.
2. Build the signing string from the path, parameters and timestamp.
3. Use the secret key to calculate the HMAC signature and attach it to the request headers.
4. The exchange recomputes the signature and accepts authentication if it matches.

The basic order and balance workflow

A typical automated-trading cycle follows these steps:

• Query balance: Calculate quantity from available assets and limit allocation according to capital-management rules.
• Create an order: Send the market, side, quantity, price and order type. Limit orders control price but may not fill; market orders prioritize execution and may receive an unfavorable price.
• Confirm execution: Query status by order ID or receive fill events through WebSockets.
• Manage risk: Place stop-loss protection. For futures, inspect leverage and liquidation conditions in the operating cycle.

Before live use, validate order handling in an exchange testnet or simulated environment and through sufficient backtesting.

Rate limits

Exchanges impose request limits, commonly by calls per second or minute, or by accumulated request weights. With an illustrative limit of 1,200 weight units per minute, requests costing five units could be made at most 240 times per minute if no other calls consumed the budget.

• Reduce repeated balance and price polling by using WebSocket updates where supported.
• Read remaining-limit information in response headers and adjust call rates dynamically.
• On HTTP 429, do not retry immediately. Back off with progressively longer waits. Repeatedly ignoring the limit may cause a temporary IP block.

API-key security: permissions and IP restrictions

An API key is an access credential. Issue it using least privilege, because exposure can endanger the account.

These additional practices are central to API-key management:

• IP allowlist: Permit only the bot server's IP so the credential cannot be used from other addresses.
• Do not hardcode secrets or commit them to Git: Use environment variables or a separate secret store, and keep keys out of screens, logs and messages.
• Rotate keys and separate them by use: This limits the scope of a single exposed credential.

Risk note: A working API connection does not guarantee profit. Disconnects, exchange maintenance, slippage, clock errors and code bugs can cause real losses. Validate a trading bot thoroughly with a testnet and small amounts, and operate only within a capital limit you can afford to lose.