blog · ~6 min read

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.

T By tradernewbie · Curated for beginners
#algorithmic#quant-trading
이 문서는 영어로 되어 있습니다. 내 언어로 볼까요? Google Translate →

번역 보기에서는 대화형 도구가 작동하지 않을 수 있습니다.

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_ohlcv with limit=1000 costs 2 weight. Use the X-MBX-USED-WEIGHT header 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 tickSize and stepSize. Submitting 0.0012345 BTC on a 3-decimal symbol returns a silent rejection. Fetch exchange.load_markets() and round with exchange.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 reqId correlation; responses arrive out of order. Maintain a dict mapping reqId → 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 genericTickList to 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

  1. Idempotency: attach a client-side order ID. On reconnect or timeout, query by ID before resubmitting. This is the single highest-leverage integration practice.
  2. Order state machine: track SUBMITTED → PARTIAL → FILLED → CANCELLED. Never assume; always transition on confirmed callbacks.
  3. Reconciliation loop: every 60 seconds, query open orders and positions from the broker and reconcile against internal state. Drift means a dropped callback.
  4. 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.

Related market data, powered by TradingView.

Educational content · Not financial advice · Trade at your own risk