Broker API Integration Practice: Exchange, IBKR, FXCM
Practical broker API integration for exchanges, Interactive Brokers, and FXCM covers rate limits, websocket reconnection, and error handling patterns.
As ferramentas interativas podem não funcionar na vista traduzida.
Broker API Integration Practice: Exchange, IBKR, FXCM
Connecting to a broker API is the step where most retail algos die. The signal works in backtest, then live integration introduces latency, disconnects, and undocumented error codes that silently drop orders. Each broker class has its own failure modes.
Crypto exchanges (Binance, Bybit, Kraken)
REST for orders, websocket for market data. Key pitfalls:
- Rate limits: Binance allows 1200 weight/minute; a single
fetch_ohlcvwith limit=1000 costs 2 weight. Use theX-MBX-USED-WEIGHTheader to self-throttle. - Websocket disconnects: every 24 hours the server forces a restart. Implement exponential backoff reconnect (1s, 2s, 4s, capped at 30s) and resync from REST on reconnect — never trust a stale stream.
- Precision: each symbol has its own
tickSizeandstepSize. Submitting 0.0012345 BTC on a 3-decimal symbol returns a silent rejection. Fetchexchange.load_markets()and round withexchange.amount_to_precision().
Interactive Brokers (TWS API / IB Gateway)
IBKR is powerful but stateful and asynchronous. Practice points:
- Run IB Gateway (not TWS) for 24/7 automation; TWS logs out nightly.
- Use
reqIdcorrelation; responses arrive out of order. Maintain a dict mappingreqId→ pending action. - Handle error codes explicitly: 1100 (connectivity lost), 200 (security not found), 201 (order rejected). Code 1100 means your live order status is now unreliable — flatten manually.
- Request market data with
genericTickListto avoid paying for ticks you don't use. - IBKR caps 50 messages per second. Burst and you get throttled with no warning.
FXCM (and similar FX brokers)
FXCM's REST API is thin. Key points:
- Subscriptions per symbol; unsubscribe to reduce noise.
- Token expires hourly; refresh proactively at 50 minutes, not reactively.
- Slippage on stop orders during news is large — use guaranteed stops only where offered, and budget 2× normal spread for NFP/CPI minutes.
Universal patterns
- Idempotency: attach a client-side order ID. On reconnect or timeout, query by ID before resubmitting. This is the single highest-leverage integration practice.
- Order state machine: track SUBMITTED → PARTIAL → FILLED → CANCELLED. Never assume; always transition on confirmed callbacks.
- Reconciliation loop: every 60 seconds, query open orders and positions from the broker and reconcile against internal state. Drift means a dropped callback.
- Latency budget: measure round-trip time. If it exceeds 250ms for crypto or 500ms for IBKR, your fills will diverge from backtest.
The integration test
Before live capital: run the integration against a paper endpoint for 14 days, deliberately kill the network every 4 hours, and verify zero duplicate or missing orders. If the test fails, the live system will fail worse.
Live Chart
Open full chart →Related market data, powered by TradingView.