Broker APIs

Keep the broker replaceable and the strategy independent.

A broker API is an execution/data interface, not your whole architecture. Put broker-specific authentication, symbols and order formats behind a small adapter.

Broker interface showing small open CFD test positions with stop loss and take profit — Hands-on screenshot: small live execution tests used to verify broker-side state and protection rules.

Technical information only: broker availability, products, leverage, API features and regulations vary by country and account. Verify current official documentation.

What to compare first

Before writing strategy code, check whether the platform offers demo/paper access, what authentication it uses, whether it has streaming data, how orders are confirmed, what rate limits apply and which features are available to your account.

Practical example

Authentication can work while trading still fails

Market data and login may succeed while an order is rejected by account permissions, minimum size, risk checks or broker-side state. Verify every layer separately.

Small open broker positions with stops and targets — Small broker-side state used to verify execution logic.

Unauthorized API response — Authentication failures should stop the workflow clearly.

Why use an adapter?

strategy.place_order(symbol, side, size)
             ↓
     internal broker interface
             ↓
Capital adapter / IBKR adapter / OANDA adapter / ...
             ↓
platform-specific request + response

This prevents session tokens, broker symbol names and response shapes from leaking through every strategy function.

Platforms commonly used for API integration

Capital.com

REST/WebSocket-oriented public API with separate demo use and session authentication concepts. Read the current official limits and account requirements before building.

Capital.com bot guide →

Interactive Brokers

Multiple developer interfaces including Web API and TWS API. Architecture differs depending on which interface you choose.

Official API portal ↗

OANDA

REST-oriented v20 API resources for account, order, trade, position, transaction and pricing workflows.

Official developer docs ↗

IG

REST trading API and related developer documentation. Test the complete deal-confirmation lifecycle rather than assuming a request equals execution.

Official IG Labs docs ↗

Saxo

OpenAPI resources including request/response and streaming concepts. Features and permissions depend on environment and account.

Official developer portal ↗

Adapter pattern

Normalize price, position and execution interfaces so the rest of the bot depends on your own internal contract.

Broker adapter guide →

Questions that save debugging time

Is there a separate demo/paper endpoint?
How are tokens created, refreshed and invalidated?
What happens when a request times out?
How do you confirm final order/deal status?
Are symbol names identical between UI and API?
What minimum sizes and market/session rules apply?
What rate limits apply to each endpoint family?

Common questions

Does every broker API work the same way?

No. Authentication, symbols, streaming, order fields, confirmations, environments and rate limits vary significantly.

Why use demo or paper mode first?

It lets you prove authentication, request formats, symbol mapping and order lifecycle without treating untested integration code as production-ready.

What is the most important adapter rule?

Keep broker-specific response shapes and credentials out of strategy logic. Translate them at the boundary into your own internal model.

Real execution evidence

Verify the final broker state

Broker trade table showing small test positions with stop loss and take profit

Broker state

Small test positions after execution

The broker interface showed the resulting BTC, ETH and SOL positions together with entry price, stop loss, take profit and current P&L. A robust bot should reconcile against this final state after requests, timeouts and retries.

Account-level totals were removed from this published crop.