Skip to main content

Keeping an up-to-date view of your orders

Seed your view from REST, keep it live off the account channel, and de-duplicate with messageId. The snapshot gives you what is resting right now; the channel gives you every change after.
  1. Subscribe to account:orders_v3_#{address} first — before you seed and before you post anything. Subscribing first means no transition slips through the gap between your snapshot and your feed.
  2. Seed from GET /orders-v3. Load the currently-resting orders into a store keyed by order.id — an id you can compute locally before you submit. Optionally tag each entry with a clientOrderId when you post; the API echoes it back, so it is a cheap way to recognize your own order later.
  3. Key your store by order.id, and de-duplicate the channel by messageId. Drop any publication whose messageId (in ctx.tags) you have already applied; otherwise write the row into your store under its order.id.

Looking up one order

GET /orders-v3/{orderId} returns a single order you own in any status. Use it when you already have an id and need the current row without paging the active list.

Get your orders

Parameters, the fifteen-field row, and the available filters.

Get an order by ID

One order, any status.

account:orders_v3

Where terminal state actually comes from.

Order lifecycle

The three statuses, all nine terminal reasons, and the correct way to test for a fill.

Which grain?

Bets, fills and positions — picking between them.
Last modified on August 11, 2026