Manage Orders

Cancelling

Four cancel routes, all returning the same shape.

# One order
curl -s -X POST http://127.0.0.1:8080/v1/orders/cancel \
  -H "Authorization: Bearer $CLOB_TOKEN" -H "Content-Type: application/json" \
  -d '{"orderID": "0x7f3a…"}'

# Several
curl -s -X POST http://127.0.0.1:8080/v1/orders/cancel-batch \
  -H "Authorization: Bearer $CLOB_TOKEN" -H "Content-Type: application/json" \
  -d '{"orderIDs": ["0x7f3a…", "0x91bd…"]}'

# Everything you own
curl -s -X POST http://127.0.0.1:8080/v1/orders/cancel-all \
  -H "Authorization: Bearer $CLOB_TOKEN"

# Everything in one market / asset
curl -s -X POST http://127.0.0.1:8080/v1/orders/cancel-market \
  -H "Authorization: Bearer $CLOB_TOKEN" -H "Content-Type: application/json" \
  -d '{"market": "0xdemo-condition", "asset_id": "100"}'

Response:

{
  "canceled": ["0x7f3a…"],
  "not_canceled": { "0x91bd…": "order not found" }
}

not_canceled maps each order hash to why it survived — already filled, already cancelled, or not yours. Cancels are not atomic across a batch: partial success is normal, so always read both fields.

Ownership is checked case-insensitively against your authenticated address.

Cancellation is off-chain only. It removes the order from the book; it does not touch your delegate allowance, which stands until you revoke it.

Querying

Your resting orders

# From the book, original order form
curl -s "http://127.0.0.1:8080/v1/orders?market=$CONDITION_ID" \
  -H "Authorization: Bearer $CLOB_TOKEN"

# Only orders above a notional threshold
curl -s "http://127.0.0.1:8080/v1/orders/value-range?min_value=100" \
  -H "Authorization: Bearer $CLOB_TOKEN"

# One order by hash (book only)
curl -s "http://127.0.0.1:8080/v1/orders/0x7f3a…" \
  -H "Authorization: Bearer $CLOB_TOKEN"

Both list routes are always scoped to your authenticated address, regardless of filters.

GET /v1/orders/{id} is a book-only lookup. A fully matched order is gone from the book and will not be found here — use the ledger-backed open-order and trade routes for history.

Open orders (from the ledger)

curl -s "http://127.0.0.1:8080/v1/open-orders?market=$CONDITION_ID" \
  -H "Authorization: Bearer $CLOB_TOKEN"

curl -s "http://127.0.0.1:8080/v1/open-orders/0x7f3a…" \
  -H "Authorization: Bearer $CLOB_TOKEN"

OpenOrder carries the fill state the book doesn’t:

Field	Meaning
original_size	Size at insert
size_matched	Filled so far
price	The order’s price
status	Ledger state
associate_trades	Trade ids tied to this order
created_at / expiration	Timestamps
type	GTC / FOK / GTD

original_size − size_matched is your remaining exposure.

Trades

curl -s "http://127.0.0.1:8080/v1/trades?market=$CONDITION_ID&limit=50" \
  -H "Authorization: Bearer $CLOB_TOKEN"

curl -s "http://127.0.0.1:8080/v1/trades/last?market=$CONDITION_ID" \
  -H "Authorization: Bearer $CLOB_TOKEN"

A TradeSummary describes one taker execution and carries a maker_orders array — every maker leg filled, with order_id, matched_amount, price and fee_rate_bps. A taker sweeping four price levels produces one trade with four maker legs, not four trades. Reconcile against maker_orders, not against the trade count.

TradeParams filters: id, owner, taker, maker, market, asset_id, limit, before, after.

Trade states

Status	Meaning
MINED	The settlement transaction landed
CONFIRMED	Finalized on Solana — this is the settlement point
FAILED	Settlement failed; affected orders have been reconciled

Solana has no reorgs, so finalized is final. Treat MINED as in-flight.

When settlement fails

A match can fail on-chain — a maker revoked their allowance, moved their balance, or the transaction ran out of compute. The executor retries what is retryable (out-of-gas gets CU ×2 and fee ×2; stuck transactions are re-executed), and on final failure it:

1. Writes UpdateTrade(FAILED) to the ledger.
2. Calls the internal POST /v1/orders/size-update on the order manager, which invalidates the still-resting orders involved.

From your side: the trade shows FAILED, and the order that backed it is no longer on the book. Re-post if you still want the exposure.

You never call size-update yourself — it is authenticated with the shared X-Internal-Token and only the executor holds it.

Ejections you didn’t ask for

Trigger	Effect
GTD expiry	The order is ejected at expiration
Game start	Every order created before the market’s start time is ejected
Failed settlement	Affected orders invalidated

The game-start eject is the surprising one: it is not selective. If you’re quoting a market with a scheduled start, expect to be flat at the whistle and re-quote deliberately.

Reconciliation loop

A dependable pattern for a bot:

1. GET /v1/open-orders — what the ledger thinks you have resting.
2. GET /v1/orders — what the book thinks you have resting.
3. GET /v1/trades since your last cursor — what filled.
4. Diff, and re-post anything that was ejected but that you still want.

Steps 1 and 2 can legitimately disagree for a moment while a settlement is in flight. Persistent disagreement means an ejection you missed.