New in v0.5.5 - Real-time order tracking with WebSocket updates
Parameters
number
default:50
Maximum number of orders to keep in state (configurable history limit)
Return Values
Order[]
Array of user orders, automatically updated in real-time. Merged from REST API initial data and WebSocket updates.
boolean
true while fetching initial orders from REST API, false once loadedboolean
true when WebSocket subscription is active, false otherwiseError | null
Error object if something went wrong during fetch or subscription,
null otherwise() => void
Function to clear the current error state
() => Promise<void>
Reconcile a fresh REST read with live orders, preserving newer live data received while the request was in flight. When the incoming row carries
version, the hook compares it first: it takes the REST row on incoming.version >= local.version and otherwise keeps local state. A versioned local row also wins over an unversioned response. Only when both sides lack version does the hook fall back to updatedAt; it retains live-only rows before applying the maxOrders limit.Features
Automatic Deduplication
Orders are automatically deduplicated by order ID. If the same order appears in both REST API response and WebSocket updates, only one copy is kept with the most recent data.Hybrid Data Loading
- Initial Load: fetches recent orders via REST (
getPaginatedOrders). - WebSocket Subscription: subscribes to the
orderschannel after the initial load. - Race Condition Prevention: the subscription only opens once the REST data is in, so an event cannot be overwritten by the response it raced.
- Subscribe-time Snapshot: the channel’s snapshot carries every resting order, and the hook reconciles it into the list.
Applying the snapshot
The snapshot lists persisted resting orders only, so it is not the whole list this hook shows. It reconciles rows it carries directly, while an omitted locally resting row needs a point read:- A snapshot row is ranked against the row already held on
version. It wins onsnapshot.version >= local.version; a lower or absent snapshot version cannot overwrite versioned local state left by the previous connection. When both versions are absent, the snapshot keeps its pre-counter precedence without comparing incompatible timestamps. - A row still showing
SUBMITTEDorPARTIALLY_FILLEDthat the snapshot omits is retained while the hook callssdk.trading.getOrder(orderId). Absence alone is ambiguous: the order may have filled or been cancelled during the outage, or persistence may lag a newer resting event the hook retained from the previous connection. Versioned results use the same ordering rule. When both rows are unversioned, the point result is accepted only if the held row did not change while the request was in flight; otherwise the hook preserves that intervening state and retries if it still needs resolution. - Terminal orders are untouched. The snapshot never carried them, so their absence says nothing.
- A snapshot row is layered over the order it supersedes, not substituted for it, so fields it does not carry —
postOnly,expirationDate,positionSide,terminalReason,conditionalOrderIdand the fee aggregates — survive.
conditionalOrderId — the take-profit or stop-loss conditional that placed a triggered close — is REST-only in the strictest sense: no order event and no snapshot row carries it, so a close this connection saw first over the socket carries no value for it. The hook does not schedule a read just because the field is missing — an order added from an OrderPlaced event is not enqueued for repair, and snapshot reconciliation leaves terminal rows alone — so the field appears only when some REST read of that order happens anyway: your own refetch, or one of the hook’s existing repair reads. Absent on orders the user placed, and on closes written before the field existed.
The fee aggregates are the one thing that can go stale rather than missing, because they accumulate with fills. A snapshot reporting a fill this connection never saw schedules the same debounced REST re-read the hook already uses, which is their only source.
If a snapshot row carries a future enum value this SDK cannot render, its validated orderId still marks that order present. The hook schedules a broad compatibility re-read for that row while continuing targeted resolution for distinct locally resting orders the snapshot omitted.
The broad REST repair is debounced and page-limited, but snapshot omissions use targeted reads because an older order may no longer fit on the newest list page. Those reads are deduplicated across repeated snapshots, limited to four in flight, and applied as each one succeeds, so a slow order does not delay its siblings. Each attempt releases its queue slot after ten seconds. If a point read fails or times out, the hook keeps the local row rather than treating that as proof the order is terminal; a later snapshot can retry it.
Real-time Updates
The hook listens to all order events:OrderPlaced- New orders added to stateOrderPartiallyFilled- Order updated with fill amountOrderFilled- Order marked as fully filledOrderCancelled- Order marked as cancelledOrderRejected- Order marked as rejectedOrderExpired- Order marked as expired
Authentication Required
This hook requires an authenticated session. Log in with theuseAuth hook (or sdk.login(...)) before using it.
Basic Usage
Filter Active Orders
Group by Trading Pair
Order History with Filters
Real-time Order Updates
Error Handling with Retry
Complete Dashboard Example
Order Type Structure
See Also
- useTrade - Place, cancel, and manage orders
- useOrderbook - Real-time orderbook updates
- WebSocket API - Low-level userOrders WebSocket channel
- TypeScript SDK - Core SDK WebSocket methods

