Orders

Orders capture exchange trading activity — instructions to swap one asset for another at a price. Connectivity exposes them as their own resource, distinct from Payments (which move a single asset on a single leg) and Conversions (atomic two-asset swaps that don't go through an order book).

The Order model#

An Order is a single record with a stable identity (reference from the upstream venue), a direction (BUY / SELL), source and destination assets, a type (MARKET / LIMIT / etc.), a status that tracks the fill lifecycle, ordered and filled quantities, time-in-force, fees, and source/destination account references on the venue.

The defining characteristic versus a Payment: an Order pairs two assets (the one you're trading from and the one you're trading to) with two account legs on the same venue. A Payment moves a single asset on a single account leg.

Every observed state change is appended to an adjustments list — that's the audit trail. The latest adjustment reflects the current top-level fields.

Lifecycle#

Listing and inspecting Orders#

curl -s "$STACK/api/payments/v3/orders?pageSize=15" \
  -H "Authorization: Bearer $TOKEN" | jq

curl -s "$STACK/api/payments/v3/orders/$ORDER_ID" \
  -H "Authorization: Bearer $TOKEN" | jq

Filter by posting a query body — for example, all open orders for a connector:

curl -s "$STACK/api/payments/v3/orders?pageSize=15" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "$and": [
      { "$match": { "connectorID": "'$CONNECTOR_ID'" } },
      { "$match": { "status": "OPEN" } }
    ]
  }' | jq

fctl does not ship orders subcommands; use the API directly.

Capability#

A connector emits Orders by implementing the FETCH_ORDERS capability. See the connector capabilities matrix for which connectors expose this.

Implementations#

• Coinbase Prime — full type, status, time-in-force, and price-precision mapping for the Coinbase Prime trading API.