Realtime Connection Model

Connection model summary

The realtime family uses one WebSocket endpoint and one subscription-control protocol.

Part	Contract
Endpoint	`wss://exchange.derivadex.com/realtime-api`
Control messages	`SUBSCRIBE` and `UNSUBSCRIBE`, each acknowledged by `ACKNOWLEDGE`
Market-data feeds	`ORDER_BOOK_L2`, `ORDER_BOOK_L3`, `MARK_PRICE`
User-data feeds	`ORDER_UPDATE`, `STRATEGY_UPDATE`, `TRADER_UPDATE`
Initial-state rule	Use REST for initial user state, then use realtime for updates

Field	Meaning
Top-level `sequence`	Global monotonically increasing server notification sequence; a connection can observe gaps because it does not subscribe to every feed update
Top-level `ordinal`	Per-connection monotonically increasing order across all subscribed feeds for that connection
`globalOrdinal`	Stable identifier over updates of one update type, used for REST pagination and reconciliation within that same update type; do not compare across different update types
`orderMatchOrdinal`	Shared identifier for all order outcomes from the same match
`ORDER_UPDATE.ordinal`	Per-outcome ordinal within one `orderMatchOrdinal` group

Feed family	First message shape	Ongoing message shape	Filtering rule
Market data	`PARTIAL` snapshot	`UPDATE` delta	Omit filters only if you intentionally want all symbols or aggregations
User data	Empty `PARTIAL`	`UPDATE` events	Filter by trader, and narrow further by strategy, symbol, or reason when available

Send SUBSCRIBE with one or more feeds and their parameter objects.
Expect ACKNOWLEDGE after each control message; the published subscribe and unsubscribe descriptions show a matching nonce, but the payload schema only requires result, so keep client request bookkeeping for fallback correlation.
Market feeds emit a populated PARTIAL first, then UPDATE messages.
User-data feeds emit an empty PARTIAL first; fetch the initial orders, strategies, or trader balances from REST before treating realtime as authoritative.
Apply messages in top-level ordinal order for one connection, use globalOrdinal to resume one update type after reconnects, do not compare it across different update types, and use orderMatchOrdinal plus ORDER_UPDATE.ordinal to reconstruct multi-outcome matches.
Use UNSUBSCRIBE with the same control-plane pattern when you want to stop one or more feeds.

Symptom	What to do next	Why
`ACKNOWLEDGE.result.error` on `SUBSCRIBE` or `UNSUBSCRIBE`	Repair the feed list or filter parameters, then resend the control message	The control-plane request failed before feed continuity was established or changed
Socket close before user-data bootstrap is complete	Reconnect, resubscribe, and redo the REST bootstrap step	User-data feeds begin with an empty `PARTIAL`, so the stream alone does not recreate prior account state
Suspected continuity loss for one update family after reconnect	Reconcile that update family with its own REST/history surface and `globalOrdinal`; do not compare ordinals across different update families	`globalOrdinal` is update-type scoped, not a universal cross-family clock
One match produces multiple order outcomes	Reconstruct from `orderMatchOrdinal` plus `ORDER_UPDATE.ordinal`	Those two fields are the public grouping model for one match with multiple consequences