order

Places one or more orders. Every order in the batch is signed together and applied in array order.

curl -X POST https://rpc.txflow-testnet.xyz/exchange \
  -H "Content-Type: application/json" \
  -H "x-api-version: 2026-08-16" \
  -d '{
  "action": {
    "type": "order",
    "grouping": "na",
    "orders": [
      {
        "a": 1,
        "b": true,
        "p": "50000.0",
        "s": "0.01",
        "r": false,
        "t": {
          "limit": {
            "tif": "Gtc"
          }
        }
      }
    ]
  },
  "signature": {
    "r": "0x<r>",
    "s": "0x<s>",
    "v": 27
  },
  "nonce": 1757992743994,
  "vaultAddress": null,
  "signatureChainId": null
}'

{
  "status": "ok",
  "code": 0,
  "data": {
    "type": "PlaceOrder",
    "data": {
      "statuses": [
        "success"
      ]
    }
  }
}

Outcome orders

For an Outcome market, a is its instrument_id. YES is the long leg and NO the short leg; b and r together encode the leg and direction:

p is the price of the traded leg, between 0 and 1: buying NO at 0.30 sends b: false, r: false, p: "0.30". Outcome orders use grouping: "na" and do not support trigger/TP-SL order types. Time-in-force must be Gtc, Gtd, or Alo; an Ioc order is rejected with Outcome limit orders only support GTC, GTD, and ALO orders, reported asynchronously on outcomeOrderUpdate.

The initial HTTP response can be an asynchronous acceptance ({"status":"ok","traceId":…}) rather than a fill. If the queued order fails, outcomeOrderUpdate pushes the reason under that traceId; successes are not pushed. Follow the matching lifecycle on outcomeOrderUpdates or read outcomeFrontendOpenOrders.

Order bodies use abbreviated keys. The long forms noted above are accepted on input, but the abbreviated keys are what the signature covers. The optional builder object is documented under Attach a builder to an order.

Order body

Price, size, and client order id

Order type

A limit order carries a time-in-force:

{ "limit": { "tif": "Gtc" } }

A trigger order carries a trigger price instead:

{
  "trigger": {
    "isMarket": true,
    "triggerPx": "48000.0",
    "tpsl": "sl"
  }
}

tpsl is tp (take-profit) or sl (stop-loss). Trigger orders are only accepted under a normalTpsl, positionTpsl, or normalTrigger grouping; sending one with grouping: "na" is rejected with Trigger orders are not supported for grouping na.

Triggered is not filled

A TP/SL that reaches its trigger price is fired, not guaranteed to execute. Two separate things happen:

1. Trigger — the protection order's trigger state becomes Triggered, and in a TP/SL pair the other side is canceled at the same moment (Canceled trigger state). This is OCO: it happens on trigger, not on fill.
2. Execution — the fired order is then submitted to the matcher like any other order, and can be fully filled, partially filled, canceled, or rejected.

A fired order that does not fill does not revert to a pending protection order — it is in a terminal state and the position is left unprotected. Common reasons the fired leg does not fill:

Because the sibling was already canceled in step 1, a failed fill leaves neither protection order live. Re-arm the protection yourself after confirming the outcome.

Confirm the result rather than assuming it: read the pair back with tpslOrders (live) and historicalTpslOrders (terminal, carrying cancelSource / cancelReason), check the resulting order on historicalOrders, and follow orderUpdates for the live transitions.

Next steps

Read resting orders back with frontendOpenOrders. To reprice or resize a resting order, use modify2.