FIX vs REST vs WebSockets for broker order flow

REST is not the safer choice for order flow just because it is simpler.

Transport does not decide whether an order is authorised, duplicated, correctly sequenced or recoverable after a disconnect. Those properties depend on the application contract, state model and controls around each connection. A broker can build a solid order path on REST, FIX or WebSockets. It can also create a compliance problem with any of them.

The useful comparison is not which protocol wins a speed contest. It is which one gives the firm enough control over intent, acknowledgements, state transitions and evidence for each workflow.

A retail app placing occasional market orders has different needs from a prop firm routing thousands of child orders per second. Many production stacks use more than one protocol, with explicit rules about where each is permitted.

Separate the transport from the order contract

REST uses discrete request-response calls, commonly over HTTPS. It is straightforward to inspect at a gateway and works well for account actions, order entry at modest rates, configuration and administrative workflows. Each request can carry an authentication token, an order payload and a client-generated identifier. But HTTP success only means the server handled the request at the transport or API layer. It does not prove that the venue accepted the order.

FIX is a persistent session protocol with defined message types and session sequencing. A buy order may arrive as a NewOrderSingle, followed by an ExecutionReport for acceptance, rejection, partial fill or fill. Sequence numbers and resend handling help recover session messages, but they do not by themselves reconstruct a firm's complete business state. Session resets, duplicate application messages and venue-specific behaviour still need explicit handling.

WebSockets provide a persistent, full-duplex connection. A provider may use one socket for commands and another for execution updates, or multiplex them.

WebSockets have no universal order schema or recovery semantics. The application must define identifiers, message sequence numbers, acknowledgements, replay windows and what happens when a client reconnects. A socket that reconnects successfully is not proof that no order event was missed.

For all three, define the business contract: what counts as accepted, how a client identifies an order, how a rejection is represented, and how the client learns that an order changed. Do not let the protocol name stand in for those answers.

Model every order as a state machine

Risk controls need to distinguish a submitted order from an accepted order. A useful minimum state model separates local intent, risk approval, dispatch, broker or venue acknowledgement, partial execution, completion, cancellation request and confirmed cancellation.

Persist transitions rather than overwriting a single status field. That makes it possible to explain what the system knew when it allowed the next action.

Consider a client that times out after sending an order. The broker may have received it and sent it onwards, even though the response did not reach the client. Blindly retrying can create a second live order.

A retry policy therefore needs a stable client order identifier, a defined idempotency scope and a lookup or reconciliation path. REST providers sometimes support idempotency keys, but the behaviour and retention period are provider-specific. FIX ClOrdID rules and WebSocket client identifiers also require agreed uniqueness and reuse rules.

Cancellation is another state transition, not a reversal. A cancel request can race with a fill, be rejected or remain unconfirmed. The risk engine should reserve exposure until the system has evidence that the order is no longer executable. If a cancel is pending, allowing replacement size without accounting for the original order can breach limits during the gap.

For each protocol, test these failure cases before launch:

• Response lost after the server or venue accepts an order.
• Duplicate command delivered after a timeout or reconnect.
• Partial fill arrives while a cancel or replace is in flight.
• Session resumes with missing, repeated or out-of-order events.
• Risk service or persistence layer is unavailable during dispatch.

A fail-closed policy is usually appropriate when the firm cannot establish current exposure. That does not mean dropping messages. It means suspending new risk, preserving the uncertain state and reconciling against the authoritative order source before resuming.

Compare the paths, not headline latency

The figures below are typical market ranges for broker or provider integrations under ordinary operating conditions. They are engineering reference ranges, not service guarantees or measurements of a named firm.

Geography, hosting, TLS termination, gateway load, venue path and market conditions can move results substantially. Measure from the process that owns the risk decision to the acknowledgement that matters.

These ranges overlap. A REST call to a nearby, well-provisioned gateway can beat a FIX session routed through several regional services.

A WebSocket feed can deliver quickly but still leave a client with stale order state if it has no replay mechanism. Measure median, 95th and 99th percentile latency, plus timeout and disconnect rates. A 20 ms median with a 2 second tail may be less useful for risk than a stable 60 ms response.

Track separate timings for client-to-gateway receipt, pre-trade decision, downstream dispatch and acknowledgement. Use a monotonic clock for elapsed time and synchronised UTC timestamps for audit correlation.

In tightly controlled environments, PTP can keep system clocks below a millisecond of error; ordinary NTP deployments may show several milliseconds of offset. Record measured offset and alert on drift rather than treating timestamps as exact.

Capacity testing should include bursts, not only average orders per second. Model rejects, cancels, mass quote changes and reconnect recovery alongside new orders. Provider rate limits are often endpoint-specific and can range from tens to hundreds of requests per second, but those are typical market ranges, not universal limits. Confirm the actual limits and throttling response for every account and route.

Make risk and compliance controls protocol-aware

Pre-trade checks should run before dispatch, not after a protocol adapter has queued the command. Reserve buying power or exposure atomically when an order passes validation. Otherwise two concurrent requests can each see the same available limit and both pass. The adapter should not be able to bypass that reservation through a different endpoint or a recovery path.

Apply controls consistently across channels, including manual dealing tools, APIs and automated strategies. Enforce entitlements by account, instrument, order type and route.

Validate price collars, quantity, notional, position limits and market status. Rate limits should protect both the broker and the downstream venue, but throttling must return a clear result and preserve the original order identifier. Silent drops create ambiguous states.

For evidence, retain the client instruction, validation result, risk decision, outbound message, provider or venue acknowledgement, subsequent execution events and any operator action. Store the raw protocol message where permitted, alongside a normalised event for search and reporting. Keep the mapping between internal order ID, client ID and downstream identifiers. Retention periods and record formats depend on jurisdiction and the firm's role, so legal and compliance teams should set the policy rather than inherit a vendor default.

Access and operational controls matter too. Use separate credentials for production and test, rotate secrets, restrict who can change routes or limits, and log configuration changes with actor and timestamp.

A kill switch should stop new orders and, where required, issue cancellations, while reporting which cancellations remain unconfirmed. Test it under load and during a downstream disconnect.

Transport acknowledgements are not evidence of a completed business action.

These controls belong in architecture reviews and ongoing monitoring. The broker technology coverage often treats platform choices as operational decisions because protocol behaviour reaches into surveillance, support and incident response.

Choose by workflow and failure mode

Use REST where request-response semantics, moderate volume and operational simplicity fit the workflow. It can be a sound choice for client order entry if the API provides stable identifiers, clear order lookup and documented retry behaviour.

Keep long-running state synchronised through an event stream or polling design with defined reconciliation rules. Do not assume a successful HTTP status is an order acknowledgement.

Use FIX where counterparties already support it, session sequencing is valuable and the team can operate session state, certification and message-level monitoring. FIX brings a mature vocabulary, not automatic safety.

Agree heartbeat intervals, reset procedures, supported message types, duplicate handling and business rules with each counterparty. An operations team should be able to see session status, last received sequence and unresolved resend requests without inspecting packet captures.

Use WebSockets where continuous updates and interactive command flow are useful, provided the provider documents delivery guarantees and recovery. Require event IDs or sequence numbers, a replay or snapshot mechanism, heartbeat behaviour and limits on subscriptions.

On reconnect, take a consistent snapshot and reconcile it with buffered events. If the provider cannot explain gap detection, treat the feed as informational until an authoritative query confirms state.

Mixed designs are common: REST for account operations, FIX for institutional order routing and WebSockets for updates or app connectivity. Put a canonical order model between these interfaces, but preserve protocol-specific details needed for audit and troubleshooting.

Test failover between routes for duplicate risk, not just availability. An alternative path that changes identifiers or acknowledgement timing can produce different exposure even when it keeps the service online.

Stop doing these things:

• Retrying a timed-out order with a new identifier.
• Treating a reconnect as proof that order state is complete.
• Releasing exposure when a cancel is merely requested.
• Recording only a normalised status and discarding the source event.

#API REST de trading #Protocolo FIX #Recuperación del estado de las órdenes #controles de riesgo previos a la negociación #broker order flow #WebSocket trading #duplicate order prevention #trading API compliance