Skip to main content
clientOrderId is an optional tag you attach to an order on POST /orders-v3. It is your own value, echoed back to you on the create response, the order row, the orders channel, and in the fills grain. clientOrderId has no effect on funds, fees, or matching.

Why it is useful

You do not know an order’s id until POST /orders-v3 responds. That makes correlation awkward when the pieces of one order’s lifecycle arrive on different paths: the HTTP response, and then separate publications on account:orders_v3_#{address}. A clientOrderId is a value you choose before you submit, so you can stitch those messages together against your own records the moment each one lands, rather than waiting on the id. This is the standard pattern on async trading platforms: attach your own reference at submit time, then match it back as updates flow in.

Format

Uniqueness

A clientOrderId must be unique per address — not just within one request, but across every order you currently have in the system. The safe rule is to treat each clientOrderId as single-use. Generate a fresh value per order.

Where it shows up

clientOrderId is echoed on the order grain: It is also echoed on the fill grain, so you can trace a fill straight back to the order that produced it:
  • GET /fills-v3 and account:fills_v3_#{address} — each fill carries the clientOrderId of the order on that side (the maker’s tag on maker rows, the taker’s on taker rows) when that order carried a tag; otherwise the field is omitted.
JavaScript

Posting orders

The submit flow this field rides on.

Time in force

The other write-only field worth recording against your tag.

Tracking your orders

Keep a local store keyed by an id you control.

Get an order by client ID

Look up one of your orders by the tag you set.

EIP-712 order signing

Why the order id is a digest, not a server-assigned value.

External user id

A per-person tag when one SX account places orders for many people.
Last modified on August 26, 2026