canceled (list of cancelled order IDs) and not_canceled (map of order IDs to failure reasons).
Cancel a Single Order
Cancel Multiple Orders
Cancel All Orders
Cancel every open order across all markets:Cancel by Market
Cancel all orders for a specific market, optionally filtered to a single token. Bothmarket and asset_id are optional — omit both to cancel all orders.
Onchain Cancellation
If the API is unavailable, you can cancel orders directly on the Exchange contract by callingcancelOrder(Order order) onchain. Pass the full order struct that was signed when placing the order.
Use the CTFExchange or NegRiskCTFExchange contract depending on the market type. See Contract Addresses for addresses.
This is a fallback mechanism — API cancellation is instant while onchain cancellation requires a transaction.
Querying Orders
Get a Single Order
Get Open Orders
Retrieve all open orders, optionally filtered by market or token:OpenOrder Object
| Field | Type | Description |
|---|---|---|
id | string | Order ID |
status | string | Current order status |
market | string | Condition ID |
asset_id | string | Token ID |
side | string | BUY or SELL |
original_size | string | Size at placement |
size_matched | string | Amount filled |
price | string | Limit price |
outcome | string | Human-readable outcome (e.g., “Yes”, “No”) |
order_type | string | Order type (GTC, GTD, FOK, FAK) |
maker_address | string | Funder address |
owner | string | API key of the order owner |
associate_trades | string[] | Trade IDs this order has been included in |
expiration | string | Unix expiration timestamp (0 if none) |
created_at | string | Unix creation timestamp |
Trade History
When an order is matched, it creates a trade. Trades progress through these statuses:| Status | Terminal | Description |
|---|---|---|
MATCHED | No | Matched and sent for onchain submission |
MINED | No | Mined on the chain, no finality yet |
CONFIRMED | Yes | Achieved finality — trade successful |
RETRYING | No | Transaction failed — being retried |
FAILED | Yes | Failed permanently |
id, maker_address, asset_id, before, after.
The Rust SDK uses cursor-based pagination via the next_cursor parameter:
Trade Object
| Field | Type | Description |
|---|---|---|
id | string | Trade ID |
taker_order_id | string | Taker order hash |
market | string | Condition ID |
asset_id | string | Token ID |
side | string | BUY or SELL |
size | string | Trade size |
price | string | Execution price |
fee_rate_bps | string | Fee rate in basis points |
status | string | Trade status (see table above) |
match_time | string | Unix timestamp when matched |
last_update | string | Unix timestamp of last status change |
outcome | string | Human-readable outcome (e.g., “Yes”) |
maker_address | string | Maker’s funder address |
owner | string | API key of the trade owner |
transaction_hash | string | Onchain transaction hash |
bucket_index | number | Index for trade reconciliation |
trader_side | string | TAKER or MAKER |
maker_orders | MakerOrder[] | Maker orders that filled this trade |
A single trade can be split across multiple onchain transactions due to gas
limits. Use
bucket_index and match_time to reconcile related transactions
back to a single logical trade.Order Scoring
Check if your resting orders are eligible for maker rebates scoring:Next Steps
Order Attribution
Attribute orders to your builder account for volume credit
Fees
Understand fee structures and maker rebates