Broker, exchange and data APIs

To automate outside MetaTrader, you connect to data and brokers through APIs. Two communication styles dominate, and they serve different needs.

REST versus WebSocket

• REST APIs — request/response over HTTP. You ask for something (recent candles, account balance, place an order) and get a reply. Perfect for actions and snapshots; you poll for updates, which adds latency and can hit rate limits.
• WebSockets — a persistent two-way connection. The server pushes updates to you the instant they happen — live quotes, trades, order-book changes. Essential for any strategy that reacts to real-time prices, because polling REST for live ticks is slow and wasteful.

A common architecture: a WebSocket stream for live market data, and REST calls for placing and managing orders and reading account state.

A conceptual sketch

import requests

# REST: fetch recent candles (request/response)
url = "https://api.exchange.example/v1/candles"
params = {"symbol": "BTCUSD", "interval": "1h", "limit": 200}
candles = requests.get(url, params=params).json()

# WebSocket: subscribe and receive a push for every update
# ws = connect("wss://stream.exchange.example/v1")
# ws.send({"subscribe": "trades", "symbol": "BTCUSD"})
# for msg in ws: handle(msg)   # arrives in real time

The realities that bite

• Authentication — API keys must be kept secret. Never commit them; load from environment or a secrets store. Use read-only or restricted keys where possible.
• Rate limits — exceed them and you are throttled or banned mid-strategy. Respect documented limits and back off on errors.
• Reconnection — WebSockets drop. A live system must reconnect and resync state, or it will trade on a stale picture.
• Idempotency — network retries can double-send an order. Use client order IDs so a retry does not open a second position.
• Clock and latency — your decisions are always slightly behind the live price; design for it rather than assuming instant fills.