FIX 4.4 vs REST vs WebSocket: Choosing Your Integration Surface
Every integration engineer at a broker, prop shop, or OMS vendor evaluating a trading platform makes the same call on day one: which API surface do we build against. The answer isn't one protocol. It's a mapping from workflow to protocol — and getting the mapping wrong is a rewrite six months in.
This playbook covers what each protocol exists for, where its latency envelope actually sits, what breaks when it's used outside that envelope, and how to think about session semantics, auth, and rate limits when the same order needs to be submittable from a FIX session, a REST call, and a browser click.
Why Three Protocols Exist
Each protocol solves a different problem the others handle badly. This isn't accident or historical accretion — it's the shape of the workflow.
FIX 4.4 is a session-based, binary-ish protocol standardised in 2003 for equities and adopted across every asset class since. It exists because institutional order flow — prime brokers, EMS/OMS vendors, algo desks, sell-side connectivity teams — already speaks it. A venue without a FIX gateway is unreachable to a large chunk of institutional capital, no matter how good the REST API is. Session-based means each connection carries state: a logon handshake, sequence numbers on every message, a heartbeat interval, and a resend protocol when a message goes missing.
REST is stateless request/response over HTTP. Every call carries its own auth, every response resolves independently, and there's no notion of a session beyond the TCP connection. That makes it the natural surface for state changes that need to be idempotent and auditable — placing an order from a browser, updating an API-key permission, pulling an account snapshot, running a scheduled reconciliation job. It's also the surface a browser can hit directly, which is why every dashboard on every venue is a REST client at heart.
WebSocket is a full-duplex framed protocol layered over an HTTP upgrade. It exists to solve the polling problem. Market data that changes 100 times a second can't be delivered efficiently via REST, and private events — fills, funding accruals, margin calls — need to reach the client the moment they happen, not on the next poll cycle. WebSocket gives the venue a persistent pipe to push events over, and it works in a browser. REST-with-callbacks does not.
A well-designed platform ships all three, because the flow that pays for the platform arrives on different pipes.
Latency Envelope by Protocol
Latency is where protocol choice gets load-bearing. The envelopes below are what a well-tuned production stack actually delivers — not vendor marketing numbers.
- FIX 4.4 in colocation: sub-millisecond order acknowledgement from a cross-connect in the same datacentre. This is the reason FIX exists — it's the only protocol that keeps wire time small enough for HFT and institutional algo flow. Outside colo (WAN over the public internet), FIX degrades to whatever the network path allows — 10-100ms depending on geography.
- REST over TLS: 20-200ms round-trip is normal, dominated by TLS handshake amortisation, HTTP framing, and JSON parsing on both sides. Fine for account queries and one-shot order submissions from a UI. Not fine for anything time-sensitive at scale.
- WebSocket after connection is established: 5-50ms per message, with the wide range driven mostly by geography and application-layer serialisation. WS beats REST here because the connection and TLS handshake are amortised across the session — no HTTP request/response overhead per message.
The practical implication: if a workflow needs sub-millisecond ack it goes on FIX. If it needs sub-second push to many clients it goes on WebSocket. If 20-200ms is fine and the request is a discrete state change, it goes on REST.
What Each Protocol Is Best For
Protocol choice per workflow, based on what the flow actually needs:
- FIX 4.4 — institutional order flow, drop-copy, allocation. New order single, order cancel/replace, execution reports, drop-copy of every fill to the OMS. Any flow originating from a sell-side desk or a prime-broker relationship arrives over FIX by default. A venue without a FIX gateway prices itself out of this flow entirely.
- REST — account state, order lifecycle mutations, config. Account balance, position snapshots, deposit/withdrawal history, API-key management, browser-initiated order submission, backoffice reconciliation queries. Anything a human triggers or a scheduled job runs. REST is also the correct surface for order submission from a UI — the latency envelope matches human reaction time, and stateless idempotency makes retries safe.
- WebSocket — market data and private-event streams. Order book updates, trade prints, ticker snapshots, funding-rate changes on the public side. Fill events, cancel confirmations, margin-call notifications, funding accruals on the private side. Anything the client needs pushed rather than polled.
The distinguishing question when routing a new workflow: does the client need to be told the moment something changes, or is polling on a schedule fine? Push goes on WebSocket. Poll goes on REST. Sub-millisecond ack from an institutional counterparty goes on FIX.
The Three Wrong Choices That Cost Time
Building an algo on REST polling. An algo polling /orderbook every 100ms burns through a rate-limit budget for information a WebSocket subscription would push for free. It also introduces variable staleness — the algo is always reasoning about a book that's up to 100ms old, which is a long time when the book is moving. Every production algo runs on WebSocket for market data with a REST fallback for reconciliation. Never the other way around.
Using WebSocket for order submission. WebSocket can carry orders and some venues expose it, but the session management gets ugly at scale. A dropped connection mid-submission means resend logic, sequence tracking, and idempotency handling that WebSocket doesn't provide out of the box. REST's stateless idempotency — with a client-supplied order ID — is much more forgiving on flaky networks. Use WebSocket for the fill notification back. Not for the order in.
Trying to integrate FIX for a browser dashboard. FIX is a binary session protocol that needs a persistent TCP connection, sequence-number state, and typically a native TCP stack. A browser cannot open a raw TCP socket to a FIX gateway. Every browser-based trading UI in production is a REST + WebSocket stack, with FIX reserved for the sell-side connectivity behind it. Bridging a FIX session through a browser via a proxy is possible — and always regretted.
Session Semantics, Auth and Rate Limits
The three protocols have three different models for session state, and it matters because the operator's engineering team needs to build correct clients against each surface.
FIX sessions carry sequence numbers on every message, in both directions. If a sender's outgoing seq-num doesn't match the receiver's expected number, the receiver requests a resend of the missing messages. The session logs in with a Logon message carrying SenderCompID and TargetCompID (identifying the two parties) and a password. Heartbeats fire every ~30 seconds; a missed heartbeat kills the session. On reconnect, the client sends the last sequence number it saw and the server replays anything missed. This is what makes FIX resilient on flaky WAN links — nothing gets lost silently.
REST is stateless by design. Every request carries an HMAC signature over the request body, timestamp, and endpoint path, verified against a per-key secret. No session, no heartbeat, no resend. Rate limits are enforced per API key and per source IP — a typical venue budget is 100 requests/second per key on private endpoints and 1000/second per IP on public market-data endpoints. Bursts above the limit return 429 and the client backs off.
WebSocket needs an application-layer session on top of the transport. The venue issues a short-lived ticket via a REST endpoint, the client sends the ticket as the first frame after upgrade, and the server binds the connection to that account. Application-layer heartbeats fire every 15-30 seconds to keep intermediaries from timing out the socket. On reconnect, a well-designed client sends the last-seen sequence number for each subscribed channel and the server replays missed events. Skipping the app-layer heartbeat is a common mistake — the socket looks alive to the OS, but the venue has already killed it upstream.
Comparison Table
| Dimension | FIX 4.4 | REST | WebSocket |
|---|---|---|---|
| Typical latency | <1ms in colo, 10-100ms WAN | 20-200ms | 5-50ms per message after connect |
| Best use cases | Institutional order flow, drop-copy, algo execution | Account state, config, UI order submission, backoffice queries | Market data, private-event streams, dashboard updates |
| Session model | Session-based with sequence numbers + heartbeat + resend | Stateless per-request | Persistent connection + app-layer heartbeat + reconnect logic |
| Auth pattern | Logon with SenderCompID + password, session-scoped | HMAC signature per request, per-key secret | Ticket-based handshake, ticket issued via REST |
| Rate limiting | Per-session message rate, TCP flow control | Per-key + per-IP, HTTP 429 on burst | Per-connection subscription limits, throttled pushes |
| When to avoid | Browser UI, ad-hoc scripts, low-volume backoffice | Real-time streams, HFT-latency flow | Order submission at scale, one-shot state mutations |
Should You Pick One or All Three
For an operator standing up a new venue — or connecting to an existing one — the mapping is close to forced.
A broker running institutional flow ships FIX first, because that's what the counterparties speak. A retail-facing broker running a browser dashboard ships REST + WebSocket first, because that's what the UI needs. A serious platform ships all three — because the same account will submit orders from a FIX session (algo desk), a REST call (backoffice cancel-all), and a browser click (dashboard user), and every fill needs to arrive over WebSocket to update the UI in real time.
The internal architecture that makes this work: all three surfaces write into the same matching engine. Order state lives in one place; the protocols are just pipes to reach it. Build it any other way — separate order-state stores per protocol — and you get reconciliation problems that never get solved. See matching engine architecture for how the engine sits underneath.
What Basis Points Ships
The Basis Points platform exposes all three surfaces against a single matching engine. REST is documented in the Scalar API reference at /docs with request/response examples, HMAC signing recipes, and rate-limit budgets per endpoint. WebSocket carries public market data channels (orderbook, trades, ticker, funding, market_status) unauthenticated, and private channels (fills, cancels, margin, funding accruals) behind a ticket handshake — with a documented 15-second app-layer heartbeat and last-seen-sequence reconnect semantics. FIX 4.4 is offered as a session gateway for institutional counterparties, with SenderCompID provisioning, drop-copy on a separate session, and colo cross-connects available at the datacentre.
The defaults reflect the team's ~30 years of combined experience shipping matching engines, hedging stacks, and venue infrastructure. Rate limits are conservative and published. HMAC signing is documented with reference client code in the languages broker integration engineers actually use. WebSocket reconnects survive engine restarts, because the client resubscribes with last-seen sequence numbers rather than replaying from zero. FIX sessions log every message to a persisted store, so a mid-session crash on either side replays cleanly.
Operators licensing the platform inherit all three surfaces on day one. The decision isn't which protocol to build — it's which counterparty flow to onboard first. See matching engine architecture for the engine below, and /docs for the reference the integration team will actually live in.
Frequently Asked Questions
Do we really need FIX if all our clients are on REST and WebSocket?
If your current book is 100% retail or crypto-native prop, no — REST + WebSocket is enough. But if the plan includes onboarding any sell-side desk, prime broker, or institutional OMS/EMS relationship, FIX isn't optional. Those counterparties won't integrate against anything else, and asking them to build a REST bridge is a non-starter.
Can we submit orders over WebSocket instead of REST?
It works, and some venues expose it, but the session management gets ugly at scale. A dropped WS connection mid-submission needs client-side resend, sequence tracking, and idempotency handling that WebSocket doesn't provide natively. REST's stateless per-request model with a client-supplied idempotency key is more forgiving on flaky networks. Use WebSocket to receive the fill event back — not to send the order in.
What's the right latency budget to plan around for each protocol?
FIX in colo: sub-millisecond ack. FIX over WAN: 10-100ms depending on route. REST over TLS: 20-200ms per call. WebSocket: 5-50ms per message once the connection is established. Anything sub-millisecond needs FIX with a cross-connect. Anything under 100ms with push semantics needs WebSocket. Anything else is fine on REST.
How should we handle WebSocket reconnects without missing fills?
The client tracks the last sequence number seen on each subscribed channel. On reconnect, the client resubscribes with those sequence numbers, and the venue replays anything missed. You also need an application-layer heartbeat (15-30 seconds) on top of the transport — intermediaries and load balancers will silently kill idle-looking sockets. Skipping the app-layer heartbeat is the classic mistake: the socket looks alive to the OS, but the venue has already dropped it.
What auth pattern does each protocol use?
FIX authenticates at session Logon with SenderCompID, TargetCompID, and a password — the entire session inherits that identity. REST signs each request with an HMAC over the body, timestamp, and endpoint path, using a per-key secret. WebSocket uses a ticket-based handshake — the client fetches a short-lived ticket over REST, sends it as the first frame after the HTTP upgrade, and the server binds the connection to that account. All three patterns are documented in the [API reference at /docs](/docs).
What are the rate-limit patterns we should plan around?
REST is per-API-key on private endpoints (typical budget 100 req/s) and per-source-IP on public market-data endpoints (typical 1000 req/s), with HTTP 429 on burst and client-side backoff. WebSocket rate-limits are per-connection on subscription count and push-frame rate. FIX rate-limits are per-session on outgoing message rate, enforced via TCP flow control and session-level throttles. Well-designed clients respect the published budgets — and use WebSocket for anything they'd otherwise be tempted to poll for.
Evaluating the platform?