Trading APIs and What Actually Happens to Your Order
From click to fill: the path an order travels and where latency is introduced.
Exeisy Intelligence DeskPublished 15 August 2026 · Updated 21 August 20268 min read
Key takeaways
- Execution infrastructure decides a real share of live performance.
- Risk validation must occur before an order is transmitted, not after.
- REST, WebSocket and FIX serve different latency and throughput needs.
- Latency requirements should follow from the strategy time horizon.
- Failure handling — reconnection, reconciliation, kill switch — defines production readiness.
Strategy discussion dominates trading education. Execution infrastructure — the machinery that carries an instruction to a venue and returns a result — receives far less attention, despite being where a meaningful share of real-world performance is decided.
The path of an order
- Signal. A strategy produces an instruction.
- Risk validation. The instruction is checked against exposure, margin and loss limits. This must happen before transmission.
- Transmission. The order is serialised and sent over an API connection.
- Broker processing. The receiving system validates and routes the order.
- Venue matching. The order meets resting interest and fills, partially fills, or rests.
- Confirmation. A fill report returns along the same path.
Every step adds time. Total round-trip latency is the sum, not the largest component.
Types of trading API
| Type | Characteristics | Typical use |
|---|---|---|
| REST | Request/response, simple, higher latency | Account queries, order placement at low frequency |
| WebSocket | Persistent, push-based streaming | Live prices, order state updates |
| FIX | Binary-efficient industry protocol | Institutional and high-throughput connectivity |
Retail-facing platforms commonly expose REST and WebSocket interfaces. Where a platform documents specific capabilities, those should be verified against its official documentation before being relied upon; capabilities differ by broker, account type and jurisdiction.
Where latency comes from
- Network distance. Physical distance to the broker's data centre sets a floor.
- Serialisation. Encoding and decoding messages.
- Queueing. Contention at the broker during volatile periods.
- Matching. Time to find counterparty interest.
For a strategy holding positions for hours, tens of milliseconds are immaterial. For one operating on intra-minute moves, they are decisive. Infrastructure requirements should be derived from the strategy's time horizon, not chosen for their own sake.
Failure handling is the real test
A production trading system is judged by what it does when things break.
- What happens if the price feed stops but the connection stays open?
- What happens if a fill confirmation never arrives?
- Is there a duplicate-order guard?
- Does the system have a hard kill switch that closes exposure?
- Is state reconciled with the broker on reconnect, or assumed?
Any system that cannot answer "what happens when the connection drops mid-order" is not production infrastructure.
Exeisy places risk validation before transmission and treats reconciliation as a first-class concern. The architecture is described in Technology.
- #trading APIs
- #execution
- #infrastructure
- #latency
Disclaimer: This article represents analytical commentary and does not constitute financial advice or a guarantee of future performance. Market conditions change continuously — verify current data before acting. AI-assisted analysis may contain errors and should be independently evaluated.
