FIX, REST and WebSockets for trading order flow

Operator A routes every order through a persistent FIX session, even though most of its flow comes from a web application. Operator B sends orders over REST and uses WebSockets for updates, reserving FIX for a small number of institutional connections.

Both choices can work. The first favours a consistent session model and operational control; the second keeps a simpler interface for clients that do not need a dedicated connection.

Consider a hypothetical broker handling 250,000 order events on a busy day, with peaks around 40 new orders a second and bursts above 100. Those figures are illustrative, not a company result. The useful decision is not which protocol is fastest in the abstract.

It is which interface gives each client the required acknowledgement behaviour, recovery path, rate capacity and support burden. Many production stacks use more than one.

Latency figures below are typical market ranges, not guarantees or audited results. They describe approximate client-to-gateway performance in regional or colocated deployments. Network distance, gateway load, serialization, risk checks and venue routing can move the result more than the protocol name. Trading Technology's platform and infrastructure coverage examines the systems around these interfaces too.

What the three choices actually provide

FIX is a session-based messaging protocol, commonly carried over a persistent TCP connection. A buy order is typically sent as a NewOrderSingle, message type 35=D. The broker responds with execution reports, 35=8, for acceptance, rejection, fills and other state changes.

A cancel request and a replace request have their own message types. Client order identifiers, original identifiers and execution identifiers let both sides correlate actions and fills.

That session brings sequencing and recovery machinery, but not automatic business correctness. A FIX session has a sender and target sequence number.

After a disconnect, a reconnecting party can request missing messages with a ResendRequest. The receiver must handle replayed messages safely, distinguish duplicates and decide when a gap fill is valid. Resetting sequence numbers to clear an unexplained mismatch can hide lost state rather than repair it.

REST is a request-response interface, usually over HTTPS. A client submits an order with a POST, then receives a response containing a broker order identifier and current status. It is straightforward to inspect with common tools and fits account services, lower-rate clients and systems that already use HTTP. But the response may mean only that the gateway received the request. It is not necessarily a venue acknowledgement, and it does not promise a fill.

WebSockets provide a persistent, two-way connection, often carrying JSON messages for both commands and events. They can support low-latency order entry and continuous private updates without a new HTTP request for every action.

Yet a WebSocket is a transport, not a standard order state model. The broker still has to define message schemas, acknowledgement meanings, sequencing, authentication, throttling and recovery. A stream that silently misses an event is not reliable just because the connection stayed open.

Typical market ranges below help set expectations. They are broad operating ranges, not service-level commitments. Measure the gateway and client path you actually run.

Choose by workload and operating model

For an institutional client sending a sustained stream of orders, FIX often earns its operating cost. Persistent sessions suit bilateral onboarding, message-level acknowledgements and controlled recovery.

A broker can apply per-session limits and maintain separate sessions for order entry and drop copy. The cost is session management: certificates or credentials, network allow-lists, sequence state, counterparty testing and out-of-hours support.

REST is usually a reasonable default for a client placing occasional orders or for administrative workflows such as account setup and order queries. It is also a useful control plane beside a streaming interface.

A client can submit an order over REST and use a stream for updates. The trade-off is that a client may open many requests during a burst, and retries after a timeout can create duplicates unless both sides agree how to identify the original request.

WebSockets fit clients that need live updates and a modestly complex command channel without the FIX session model. They can reduce request overhead and keep one authenticated channel open for order events, fills and account updates. They need careful limits on subscriptions and outbound queues. If a client cannot drain messages quickly enough, the server needs a policy: disconnect, drop non-critical data, or apply backpressure. Quietly growing an unbounded queue turns a slow consumer into a memory incident.

A mixed design is common. For example, a broker might expose REST for order entry to lower-volume integrations, WebSockets for private event delivery, and FIX for professional clients and venue-facing connectivity. The client-facing protocol should not dictate the internal order model. Normalise requests into a canonical command, run risk and entitlement checks once, then publish state changes from the order-management service.

Set the acknowledgement contract before choosing an interface. Distinguish at least these states:

• Received: the edge gateway parsed the request and assigned or recognised a client request identifier.
• Accepted: internal validation and risk checks passed, and the order is live in the broker's system.
• Routed or acknowledged: the downstream venue or liquidity provider accepted the order.
• Part-filled, filled, cancelled or rejected: subsequent events that update the order's state.

Record timestamps at gateway receipt, risk decision, route submission, downstream acknowledgement and client delivery. At typical retail or broker API volumes, percentiles matter more than a single mean: track p50, p95 and p99 latency, plus timeout and rejection rates.

Keep client-to-edge network time separate from internal processing and downstream time. Otherwise a venue delay can look like a slow API, or a slow risk service can be blamed on the network.

Build failure handling into the order path

The difficult moment is not a clean submission. It is a timeout after the broker has accepted an order but before the client has received the response.

A blind retry can submit a second order. Give every client request a stable identifier and define duplicate behaviour at the gateway. REST APIs may support an idempotency key, but do not assume they do. With FIX, use the agreed client order identifiers and process retransmissions according to session rules. In either case, expose a way to query the known order state.

WebSocket clients need the same discipline. A reconnect does not establish what happened during the gap. The API should provide a sequence or cursor for private events, a documented replay window where feasible, and a snapshot or query path to compare the client's view with the broker's authoritative state. If replay is unavailable, tell clients to fetch open orders and recent executions after reconnect. A fill should not disappear because the stream dropped for three seconds.

Use this implementation sequence to make protocol differences explicit before production:

1. Write the state machine. Define valid transitions, including partial fills, cancel-pending states, rejects and late fills. Decide which service owns each transition.
2. Specify acknowledgement semantics. State exactly what each response confirms, what identifiers are returned and which downstream events follow.
3. Set capacity and backpressure limits. Model normal and burst rates per account, connection and gateway. Load-test at the expected peak plus headroom, and test what happens when a client exceeds its allocation.
4. Make retries safe. Test duplicate submissions, delayed responses, client reconnects and cancel requests that race with fills. Return a queryable outcome rather than asking the client to guess.
5. Test recovery as an operational procedure. For FIX, exercise sequence gaps and resend handling. For REST and WebSockets, exercise timeouts, snapshots and event gaps. Include a restart of the gateway, not only a network interruption.
6. Instrument the whole path. Carry a correlation identifier across gateway, risk, order management and routing. Alert on stale sessions, queue depth, sequence gaps, rejection spikes and reconciliation differences.

Keep the canonical order record durable before telling the client that the order is accepted. That does not mean every interface must wait for a venue response.

It means the response must match a persisted state, with clear ownership of the next event. Retain execution identifiers and deduplicate downstream events. Reconciliation should compare open orders, executions and balances, not just count messages.

Operational runbooks should include a controlled way to pause new orders without losing cancel access, a policy for stale sessions, and named ownership for replay and reconciliation. A broker may choose different thresholds by product or client tier, but should document them. Further trading infrastructure analysis can help frame the surrounding platform choices; the interface itself does not remove the need for operational controls.

Make the decision at the boundary

Pick the interface per client and workflow, then keep the internal order lifecycle consistent. FIX is a strong fit where counterparties need a standard session, sequencing and a defined bilateral operating model. REST is effective for lower-rate request-response actions and simple integrations. WebSockets suit continuous updates and interactive clients, provided the application protocol includes recovery and backpressure rules.

Before committing, run a representative test rather than comparing protocol labels. Test at expected peak volume, with realistic risk-check latency and downstream delays.

Measure p50, p95 and p99 acknowledgement times, CPU per message, queue depth and disconnect recovery. Verify throttling from the client's perspective. A fast median is not useful if bursts produce a backlog or a reconnect leaves order state ambiguous.

Then price the operating model. A FIX deployment can mean a session per client, certification work and 24-hour session monitoring. A REST and WebSocket API can reduce onboarding friction but shift effort into token security, schema versioning, subscription controls and client support. Track integration effort and incident load alongside latency. The best interface is the one the organisation can operate safely at its expected volume, not the one with the shortest demo response.

This advice does not apply where a venue or regulator mandates a specific interface, or where a strategy depends on deterministic, colocated access with measured microsecond-level latency. In those cases, the required connectivity and execution environment set the design, and a general broker API comparison is not the deciding factor.

#FIX protocol order entry #REST trading API #WebSocket trading API #broker order management #order acknowledgement latency #FIX session recovery #trading API architecture #prop firm infrastructure