FIX, REST and websockets for broker order flow

Price the failure before choosing a protocol

A bad order-flow integration can put $10,000 to $100,000 of exposure on a broker's book before the team detects the problem. That is a typical planning range for a live incident involving duplicate orders, a missed cancel or a broken execution report path, not a prediction of any firm's losses. The exposure can grow quickly when order rates rise and the system cannot establish which orders reached the venue.

The choice between FIX, REST and websockets is not a contest over which protocol is fastest. It is a decision about how an order is submitted, how its state is confirmed, and how that state is recovered after a timeout or disconnect. A broker may use all three: FIX for venue order entry, REST for administrative and recovery requests, and websockets for pushed account or order updates.

Start by mapping each order state from client instruction to venue acknowledgement, fill, cancel or reject. Record which component owns the authoritative state at each step. [Trading Technology's infrastructure coverage](https://tradingtechnology.org/) examines the systems and controls that sit around these interfaces, but the relevant limits still come from your counterparties' specifications and your own tests.

A successful network write is not proof that an order was accepted.

That distinction should shape the design. A request can reach a server while its response is lost. Retrying without an idempotency mechanism or a state check can create a second live order. Conversely, treating every timeout as a rejection can leave a real order unmanaged. The implementation needs an explicit answer for both cases.

What each interface guarantees, and what it does not

FIX provides a session model for ordered messages, sequence numbers, heartbeats and recovery requests. That makes it a common choice for broker-to-venue order entry and execution reports.

It does not define every venue's business rules. Supported message types, required fields, session resets, throttles and cancel-replace behaviour are set by the counterparty's implementation guide.

REST usually fits request-response operations: submit an order, request a cancel, retrieve an order or query a position. Its simplicity helps with integration and operational tooling.

But an HTTP success response can describe receipt by an API gateway rather than acceptance by a matching engine. A timeout after a POST leaves an uncertain outcome unless the API supports an idempotency key, a client order identifier lookup or another reliable reconciliation path.

WebSockets maintain a connection for server-pushed events. They can reduce the delay between an execution or account update and its arrival at a client, and they avoid repeated polling.

They are not, by themselves, a standard order-entry protocol. Implementations differ on authentication renewal, message ordering, replay, snapshot recovery and whether an event is durable. A disconnected client must know how to rebuild state rather than assume it received every update.

The figures below are typical market ranges for initial capacity planning, not protocol guarantees. Network location, vendor throttles, payload size and application design can move results substantially. Confirm limits in the relevant technical specification and load test the actual path.

These ranges are useful for sizing a test, not for promising latency or throughput. A provider may impose much lower burst limits, and a single busy symbol or account can concentrate traffic on one connection. Measure end-to-end acknowledgement and update delay separately from transport latency.

Choose a boundary, not a winner

For each integration, define a command path and an event path. The command path accepts an instruction and returns a durable internal reference. The event path reports acknowledgement, rejection, fill and cancel status. These paths may use different protocols, but they must resolve to the same internal order identity and state machine.

Keep protocol-specific parsing and session handling at an adapter boundary. The core order service should work with a stable internal model: client order ID, broker order ID, venue order ID, instrument, side, quantity, limit price, time-in-force and current state.

Preserve the raw inbound and outbound message, with timestamps and correlation IDs, for investigation. Do not rely on a display label or a mutable database row as the only record of what was sent.

Useful design checks include:

• Give every new instruction a unique client order ID and define its lifetime and reuse rules.
• Make retries conditional. Look up the existing order or use the provider's documented idempotency mechanism before resubmitting.
• Persist an outbound command before transmission, then record the transport result separately from the venue's business response.
• Sequence and deduplicate incoming events. If the provider supplies no sequence, define a snapshot and reconciliation procedure.
• Set explicit back-pressure limits. Queueing can protect a downstream service, but a growing queue adds stale orders and delays cancels.

Choose FIX where the venue supports a well-defined session and the expected order rate or operational model warrants it. REST can be the better fit for a small integration with modest traffic and strong lookup semantics.

WebSockets are valuable for timely event delivery, provided there is a tested path to recover missed state. Some providers expose order submission over WebSockets; treat that as a provider-specific API, not as interchangeable with FIX.

A 30-day implementation plan

Allocate four weeks to establish the interface, build the adapter and prove failure handling. This assumes one venue or provider, a small engineering team and access to a test environment.

Additional venues, certification windows or incomplete specifications can extend the schedule. Keep the implementation narrow until the order and recovery semantics are understood.

1. Days 1 to 4: map behaviour and constraints. Collect the protocol specification, rate limits, certification requirements and support contacts. Draw the order lifecycle and document acceptance, rejection, cancel, replace, partial-fill and timeout cases. Agree the source of truth for each state and set measurable limits for acknowledgement latency, event lag and unresolved orders.
2. Days 5 to 9: define identities and failure rules. Specify IDs, persistence, retry behaviour, duplicate detection, event ordering and reconciliation. Write a decision table for uncertain outcomes, including what happens when a submit times out, a cancel response is lost or a websocket reconnects. Review the table with operations and compliance before coding around assumptions.
3. Days 10 to 16: build the adapter and observability. Implement the session or API client, validation, durable command log and normalised order events. Add structured logs with correlation IDs, metrics for rejects, timeouts, sequence gaps and queue depth, and alerts tied to operational action. Keep raw messages available under appropriate access controls and retention rules.
4. Days 17 to 23: test normal and degraded paths. Run functional cases for new, amend, cancel, reject and partial fill. Then inject delayed responses, duplicate events, disconnects, process restarts and rate-limit responses. Replay recorded traffic where available. Verify that a restart can rebuild open-order state and that a retry cannot silently create a duplicate.
5. Days 24 to 30: certify, shadow and release by limit. Complete provider certification and compare the adapter's state against the provider's records in a controlled environment. Shadow or simulate production-shaped traffic before enabling live orders. Release behind a feature flag with a conservative order-rate cap, a staffed rollback procedure and a named owner for reconciliation. Increase limits only after the event and recovery metrics remain within agreed tolerances.

Use the plan to make decisions visible, not to force a production date. A useful gate at day 9 is whether the team can explain every uncertain outcome without saying "retry and see".

At day 23, require evidence that a process restart and a dropped connection do not leave open orders unaccounted for. The broker infrastructure reference material can help frame operational questions, but provider-specific certification remains the controlling requirement.

Prove recovery, then stop doing these things

Operations should be able to answer, at any point, how many orders are open, which acknowledgements are outstanding, how old the oldest unresolved command is, and whether the local state matches the provider's state. Alert on age and divergence, not only on connection status. A green socket can carry stale or incomplete information.

Set thresholds from measured traffic. For example, a team might alert when an acknowledgement exceeds 500 ms, an event stream is more than one second behind, or an unresolved order remains open for five seconds.

Those are starting points, not universal service levels. A venue's normal latency, instrument liquidity and market hours affect what is operationally meaningful. Review thresholds against test and production distributions, including busy periods.

Run a routine reconciliation that compares local open orders and executions with the provider's records. Define who can halt new submissions, who can cancel or manually investigate, and how the team records decisions during an incident.

Test those actions in a controlled environment. Keep the client-facing status conservative: an uncertain order is pending investigation, not rejected, until evidence resolves it.

Stop doing these things:

• Stop retrying timed-out submissions without checking whether the order exists.
• Stop treating a connected websocket as proof that no events were missed.
• Stop coupling venue-specific fields and session logic to the core order state machine.
• Stop raising rate limits before testing throttling, queue growth and recovery.

#API REST de trading #gestión de órdenes del broker #recuperación de sesiones FIX #FIX order entry #websocket order updates #execution reports #order state reconciliation #trading API failover