New in v0.5.4 - Real-time user movement tracking
useUserBalances for the live balance change a fill produces.
In that history, balanceBefore / balanceAfter / lockedBefore / lockedAfter describe a spot balance row. A margin fill leg and a FUNDING row have no spot row and report 0 in all four: that is “no spot snapshot”, not a wallet balance of zero. Read margin account state for collateral rather than these fields.
Parameters
The hook accepts an optional options object.number
default:50
Maximum number of movements to keep in memory
number
Number of movements to fetch from the API on initial load (default:
maxMovements, max: 100)LedgerEntryType
Filter the initial REST history by entry type. Changing this value re-fetches history. Live WebSocket events are not filtered by the hook.
TransactionType
Filter the initial REST history by transaction type. Changing this value re-fetches history. Live WebSocket events are not filtered by the hook.
string
Filter the initial REST history by asset UUID. Live WebSocket events are not filtered by the hook.
Return Values
UserMovementEvent[]
Array of movement events, newest first. Automatically deduplicated by movement ID.
boolean
true while fetching initial movements, false once loadedboolean
true after the channel handler is registered, false otherwise. This does not report socket connection or channel delivery state.Error | null
Error object if something went wrong,
null otherwise() => void
Dismisses the current error. It does not retry the request or re-register the handler.
Features
Automatic Deduplication
The hook automatically deduplicates movements by ID. If the same movement is received multiple times (e.g., from WebSocket and initial fetch), only one copy is kept.Hybrid Data Loading
- Initial Load: Fetches recent movements via REST API
- Real-time Updates: Registers a WebSocket channel handler for new movements
- Race Condition Prevention: WebSocket handler registration only starts after REST data is loaded
Memory Management
Movements are automatically limited tomaxMovements entries. Older movements are removed when the limit is exceeded.
Basic Usage
Filter by Transaction Type
Filters are applied server-side on the initial REST fetch. Changing a filter value automatically re-fetches history, but the hook appends all live WebSocket events. Filter the returned array in the client when the live view must remain restricted. REST history values may be uppercase while WebSocket values may be lowercase, so normalize before comparing.Filter by Entry Type and Asset
The REST request usesassetId, but the v1.0.51 REST-to-event adapter does not retain that field. To keep the merged history and live feed restricted to one asset, also compare the token address carried by both sources.
Group by Token
Track Order Lifecycle
Inspect a Movement Balance Snapshot
balanceAfter and lockedAfter describe the balance immediately after that movement; they are not a current-wallet-balance API. Use useUserBalances or sdk.profile.getUserBalances() when you need current balances. A missing snapshot means unavailable data, not zero.
Error Handling
Complete Example with Styling
Movement Event Structure
tokenAddress: Required legacy alias populated fromtoken(or the older wire alias)symbol(optional): Token ticker symbol (e.g., “BTC”, “USDC”)amount: Human-readable decimal string and the simplest exact value to displayamountRaw(optional): Do not assume this value exists or is an integer. Funding history may contain a decimal string; integer raw-unit conversion applies only after validating a token movement’s value.entryTypeandtransactionType: REST history may use uppercase values while WebSocket events may use lowercase values. Normalize casing before comparisons.
See Also
- WebSocket API - Low-level movements WebSocket channel
- TypeScript SDK - Core SDK WebSocket methods
- useProfile - User profile and balance queries

