Skip to main content
New in v0.5.5 - Real-time order tracking with WebSocket updates
Subscribe to real-time updates for all your orders. Automatically fetches initial orders via REST API and keeps them synchronized with WebSocket events.

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 loaded
boolean
true when WebSocket subscription is active, false otherwise
Error | 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

  1. Initial Load: fetches recent orders via REST (getPaginatedOrders).
  2. WebSocket Subscription: subscribes to the orders channel after the initial load.
  3. Race Condition Prevention: the subscription only opens once the REST data is in, so an event cannot be overwritten by the response it raced.
  4. 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 on snapshot.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 SUBMITTED or PARTIALLY_FILLED that the snapshot omits is retained while the hook calls sdk.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.
selfTradePreventionMode is unreliable on this hook, as of v1.0.60. Rows seeded from REST carry it — the hook’s initial getPaginatedOrders load and its getOrder repairs both return it on Order. But orderFromEvent and orderFromSnapshotItem do not map it through, so a row that first appears from a live event or a subscribe-time snapshot omits it even though the underlying frame carries the value. Absence is therefore not evidence the order carried no override — unlike postOnly, where absence is meaningful. Where the requested mode matters, read it from sdk.trading.getOrder or the core sdk.ws.userOrders stream rather than from a row this hook built from stream data.
  • A snapshot row is layered over the order it supersedes, not substituted for it, so fields it does not carry — postOnly, expirationDate, positionSide, terminalReason, conditionalOrderId and 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 state
  • OrderPartiallyFilled - Order updated with fill amount
  • OrderFilled - Order marked as fully filled
  • OrderCancelled - Order marked as cancelled
  • OrderRejected - Order marked as rejected
  • OrderExpired - Order marked as expired

Authentication Required

This hook requires an authenticated session. Log in with the useAuth 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