FIX API, defined
The Financial Information eXchange (FIX) protocol is an open, vendor-neutral standard for communicating trade-related messages electronically. First developed in the early 1990s to replace phone-based dealing between institutions, it has become the common language of electronic markets. A FIX API is simply the interface a broker or trading firm uses to speak that language: instead of clicking in a terminal, its systems send and receive structured FIX messages to a counterparty's servers.
In practical terms, FIX lets a broker connect straight to a liquidity provider — or to a Prime of Prime — and stream live prices and route orders programmatically. There is no manual screen in the loop; the broker's platform, risk system or liquidity bridge exchanges messages directly with the provider at machine speed. That direct, standardised connectivity is why FIX underpins most institutional order flow.
How a FIX session works
FIX is session-based, which means the two parties establish a persistent, authenticated connection and keep it alive for the trading day. A session typically follows this rhythm:
- Logon. The initiator sends a Logon message with credentials to the provider's endpoint, opening the session.
- Heartbeat. Both sides exchange Heartbeat messages at an agreed interval to confirm the connection is alive; a missed heartbeat triggers a Test Request and, if unanswered, a disconnect.
- Messages. During the session, application messages flow in both directions — quote streams, orders, cancels and execution reports — each with a sequence number so nothing is lost or duplicated.
- Logout. A Logout message closes the session cleanly at end of day or on demand.
Sequence numbering and the heartbeat mechanism are what give FIX its reliability: if messages are missed, the protocol can request a resend, so both sides stay synchronised even across brief interruptions.
FIX API vs REST API
Many firms ask how FIX compares with a REST API, since both let systems talk to a provider. They suit different jobs. FIX is built for continuous, low-latency order flow; REST is a simpler request-response web protocol that is easier to build against but generally slower. The table summarises the practical differences.
| Dimension | FIX API | REST API |
|---|---|---|
| Latency | Low; a persistent session designed for real-time flow. | Generally higher; each call opens a request-response cycle. |
| Use case | High-volume order routing and live price streaming. | Account data, config, lighter or periodic integrations. |
| Message type | Session-based, structured FIX messages (tag=value). | Stateless HTTP requests, usually JSON payloads. |
| Who typically uses it | Banks, brokers, liquidity providers, institutional desks. | Retail apps, lighter integrations, developer tooling. |
Structural comparison. Neither is universally better — the right choice depends on latency needs, volume and the counterparty's supported connectivity.
Why institutions prefer FIX for liquidity access
For institutional execution, three properties make FIX the default. First, speed: a persistent session avoids the overhead of repeatedly opening connections, which matters when prices change many times a second. Second, reliability: sequence numbers, heartbeats and resend logic keep both sides in sync and make gaps recoverable. Third, standardisation: because the message format is an open industry standard, a broker can integrate many providers using one well-understood protocol rather than a bespoke interface per counterparty. Together these let firms route high volumes directly to liquidity with the consistency institutional trading demands.
FIX in the broker → PoP → bank chain
FIX is the connective tissue running through the whole liquidity chain. A broker's platform or bridge holds a FIX session to a Prime of Prime; the PoP, in turn, holds FIX sessions to the tier 1 banks and non-bank market makers it aggregates. When a client trades, the order travels as a FIX message from the broker to the PoP, which routes it on to the best underlying source, and the resulting fill returns as a FIX execution report back down the same path. Because every layer speaks the same protocol, the chain behaves as one continuous, low-latency pipe rather than a series of translations. Our companion piece on how brokers connect to liquidity sets this in the wider context of bridges and direct connectivity, and what direct market access is covers the routing model FIX enables.
Common FIX message types
You do not need to read raw FIX to understand a handful of core message types that carry most trading activity:
- NewOrderSingle. Submits a single order — specifying instrument, side, quantity and order type — to the counterparty.
- ExecutionReport. The reply that confirms an order's status: accepted, filled, partially filled, rejected or cancelled.
- OrderCancelRequest. Requests cancellation of a working order.
- MarketDataRequest / MarketDataSnapshot. Subscribes to and delivers streaming quotes and depth.
Most order-flow interactions reduce to a NewOrderSingle going out and one or more ExecutionReports coming back, which is why those two are the messages integrators check first.
What to check before a FIX integration
Before connecting over FIX, confirm the practical details that determine whether the session will work smoothly. Check the FIX version the counterparty supports and its specification document, which lists the exact tags and message types it expects. Confirm the endpoint, credentials and network path, including whether a cross-connect or VPN is required and where the servers are hosted, since proximity affects latency. Test in a UAT / staging environment first, validating logon, heartbeats, order placement and execution reports before going live. Finally, agree support and monitoring arrangements so session drops or rejects are caught and resolved quickly. Our technology desk works through this checklist with every counterparty during onboarding, and the glossary defines the supporting terms used here.