Skip to main content
Every order — resting quote or immediate bet — goes through POST /orders-v3. The field-by-field reference lives on the endpoint page.

Prerequisites

A deployed, funded proxy is required before any OBv3 orderPOST /orders-v3 rejects with 400 PROXY_NOT_DEPLOYED until then. See Deploy a proxy wallet.
You also need your API key, sent as x-sx-api-key. See Authentication and API key.

Steps

  1. GET /metadata/obv3 — chain id, Escrow address, active token, ladder step, size limits.
  2. Round your odds down onto the ladder — a multiple of oddsLadderStepSize × 10^15. See Odds rounding.
  3. Choose a timeInForceGTC to rest, IOC/FOK to execute now. See Time in force.
  4. Sign the eight-field EIP-712 Order struct.
  5. POST /orders-v3 — expect 200 and a per-order result carrying SUBMITTED, the server-assigned commandId, and your clientOrderId / externalUserId if you set them.
  6. Wait for ACTIVEPENDING is not live. Watch your account:orders_v3 stream for the transition instead of polling. Or set waitForOutcome: true to have the call wait and return each order’s terminal outcome inline.
Posting an order does not lock capital, regardless of timeInForce. Funds are only escrowed when the order matches — see Risk limits.

Posting a GTC order end to end

Output:
A non-zero expiry that falls inside the market’s betting delay plus two seconds is rejected. Resolve the delay from bettingDelay on GET /metadata/obv3.

Batching

POST /orders-v3 takes an array of up to limits.maxCreateOrders orders (currently 10), one shared maker per batch — the full field rules are on Create orders.
  • One maker per request. Every order in the batch must carry the same maker. Mixed makers are a 400.
  • Batches are not atomic. Each order gets its own entry — orderId, status (SUBMITTED/FAILED), commandId, and clientOrderId / externalUserId when you set them — in the response orders array, and a partial outcome is normal. When you request waitForOutcome, each SUBMITTED entry also carries an outcome object with its terminal state; FAILED entries never carry an outcome. There is one exception: a duplicate clientOrderId fails the whole batch. Always read every entry in the array.

Dust remainders

A partial fill that would leave a remainder below limits.minRestingOrderSizeBaseUnits (0.1 USDC, or 100000 base units) does not rest that remainder — the engine discards it. The order then goes terminal: status: "INACTIVE" with inactiveReason: "FILLED".

Re-quoting

There is no amend. To move a price: cancel, then post a new order.

Create orders

Every field, every validation rule.

Taking liquidity

The same signing and submission path, from the taker’s side.

Time in force

Choosing between GTC, IOC and FOK.

Tracking your orders

Reading your own orders back, and what the API will not tell you.

Market making

Quoting, exposure and re-quote loops.

External user id

Tag orders when one SX account places bets for many people.
Last modified on August 19, 2026