> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kuru.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Following Account Activity

> Connect a wallet identity to balances, orders, and executions.

Use account data to reconcile what actually happened after a transaction. A Relay broadcast response does not establish that an order is resting or that balances have changed.

## Resolve the account

For direct chain reads, resolve the owner with `rootAccountIdOf` and select the target root or child ID. Children have no address. The hosted [Resolve user address](/api/data-source/reference/resolve-user) endpoint provides the address-to-user lookup. An unregistered address returns `userId: null` under that documented schema.

Use the account being traded, not automatically the secondary signer or sponsor address. A signer can act for a different funded account.

## Initial state and subscriptions

Load [finalized balances](/api/data-source/reference/user-balances) and [open orders](/api/data-source/reference/user-orders). Each response has its own cursor. When both its epoch and sequence are present, install that snapshot and subscribe to the corresponding finalized user stream after that cut.

Do not reuse a cursor from a different dataset without the API's documented guarantee. For user orders and balances, subscribing without `seq` can establish a fresh authoritative snapshot.

## Apply updates

Replace local state on a full snapshot. Apply deltas in order after validating their predecessor. For orders, distinguish creation, partial or complete execution, cancellation, and RAB reduction. Match the order ID before mutating a reused slot.

A submitted order may be skipped, immediately filled, or left resting. Use transaction outcomes together with [user orders](/api/exchange/websocket-reference/user-orders) and [user trades](/api/exchange/websocket-reference/user-trades), rather than requiring every successful action to appear in open orders.

## History and completeness

The [order-event endpoint](/api/data-source/reference/order-events) is completion-oriented history; it excludes partial fills. Use user trades for execution history.

REST snapshots are bounded. If `truncated` is true, do not present the response as the complete account state or use it alone to authorize a cancel-all workflow. User WebSocket streams provide full snapshots according to their reference semantics.

Balances contain available and active-order-reserved funds. Passive positions are accounted for separately. See [Balances and Open Orders](/accounts/balances-and-reservations).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.