Orders and fills

Place, inspect and reconcile market and limit orders. Retain order identity throughout the request lifecycle.

All mutations require account scope and idempotency. API access permission is not spending authority. The accepted order must retain the EIP-712 OWNER authorization or other approved economic authority and the operation that acknowledged it. A stable orderId and account-scoped clientOrderId are distinct from the monetary nonce and the HTTP idempotency key.

Illustrative limit-order request#

All order examples below are synthetic proposed HTTP contracts. They show unsigned economic payloads; production authentication and owner-signing envelopes are not supplied. Do not submit these examples to a live host.

POST /v1/trade/order
X-Omega-Account-Id: 0x2222222222222222222222222222222222222222
Idempotency-Key: order_demo_limit_1
Content-Type: application/json

{
  "market": "USD6-EUR6",
  "baseAssetId": "asset_demo_usd6",
  "quoteAssetId": "asset_demo_eur6",
  "side": "BUY",
  "type": "LIMIT",
  "quantity": "25000000",
  "limitPrice": "920000",
  "timeInForce": "GTC",
  "clientOrderId": "treasury-rebalance-17"
}

Use exact base and quote asset representations and the documented price scale when a versioned order contract becomes available. An acknowledgement means accepted for processing; it does not establish a fill or final settlement.

Illustrative market-order request#

POST /v1/trade/order
X-Omega-Account-Id: 0x2222222222222222222222222222222222222222
Idempotency-Key: order_demo_market_1
Content-Type: application/json

{
  "market": "USD6-EUR6",
  "baseAssetId": "asset_demo_usd6",
  "quoteAssetId": "asset_demo_eur6",
  "side": "SELL",
  "type": "MARKET",
  "quantity": "100000000",
  "maxSlippageBps": 25,
  "minOutputAmount": "91770000",
  "clientOrderId": "liquidity-sweep-4"
}

The protection fields, fill policy and rejection behavior are proposed. In this six-decimal example, a 100 USD6 sale at a reference price of 0.92 EUR6/USD6 produces 92 EUR6 before fees; a 25 bps price bound is 91.77 EUR6 (91770000 atomic units). This is arithmetic test data, not a live rate or net-after-fee promise. Monetary authority must bind a maximum input or minimum output constraint; a market order must fail explicitly on insufficient liquidity rather than execute without bounds.

Order fields and acknowledgement#

Proposed acceptance uses this operation acknowledgement envelope:

HTTP/1.1 202 Accepted
Content-Type: application/json

{"version":"0.1-review","requestId":"request_demo_3","data":{"operationId":"order_operation_demo_1","accountId":"0x2222222222222222222222222222222222222222"}}

Persist the original request and idempotency key before submitting. HTTP 202 acknowledges processing; it does not mean the order is open or filled. Order-operation projections and an authoritative lookup contract remain unresolved and are required before this recovery path can be used.

Read and reconcile an order#

Proposed request:

GET /v1/trade/order?orderId=order_demo_1
X-Omega-Account-Id: 0x2222222222222222222222222222222222222222

Proposed response for a limit order with a partial fill:

{"version":"0.1-review","requestId":"request_demo_4","data":{"accountId":"0x2222222222222222222222222222222222222222","orderId":"order_demo_1","clientOrderId":"treasury-rebalance-17","operationId":"order_operation_demo_1","market":"USD6-EUR6","baseAssetId":"asset_demo_usd6","quoteAssetId":"asset_demo_eur6","side":"BUY","type":"LIMIT","limitPrice":"920000","quantity":"25000000","filledQuantity":"10000000","remainingQuantity":"15000000","state":"PARTIALLY_FILLED","updatedAt":"2026-10-05T12:00:01.000Z"}}

filledQuantity + remainingQuantity equals the original quantity. FILLED describes matching completion; settlement still needs its own observation. GET /v1/trade/account/trades supplies fill IDs, order IDs, exact asset amounts, fee entries and settlement-operation links. A cancelled remainder must not erase earlier fills or their fees.

Use GET /v1/trade/orders for open-order pagination and GET /v1/trade/orders/history for terminal orders. Proposed filters include account-scoped market and time bounds, bounded limit and opaque cursor. Retain filters across pages; reconcile by stable order/fill ID, not arrival order. Private reads require current access even when the ID is known.

Cancel, amend and batch#

Proposed cancellation request:

DELETE /v1/trade/order
X-Omega-Account-Id: 0x2222222222222222222222222222222222222222
Idempotency-Key: cancel_demo_1
Content-Type: application/json

{"orderId":"order_demo_1"}

Cancellation acknowledgement follows the proposed 202 operation envelope. It is a request, not confirmation of CANCELLED. Read the order after acceptance and preserve fills and their fees. Final cancellation/fill precedence requires a released contract. Only an eligible unmatched lock may be released. Never retry a lost cancellation response with a new key or treat a stream disconnect as cancellation.

PUT /v1/trade/order, batch submit and batch cancel are part of the target specification. Their detailed mutation schemas remain unresolved. No amendment priority, atomic cancel-replace, batch-wide rollback or cancel-all cutoff is promised. For the first integration, track individual order IDs and reconcile each mutation separately.