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.

Auto-conversion to reduce-only

On a perpetual, an order you sent with r: false can come back as a reduce-only order. When the available margin in your perp account does not cover the order's required margin, the node does not reject it outright — it first checks whether the order would only shrink an existing position, and if so flips r to true and places it with no margin frozen.

All of the following must hold, or the order is rejected with Insufficient margin in account as before:

Two consequences to plan for:

• The converted order can no longer open or flip. It will only shrink the position, and the remainder past the position size is not placed.
• Attached TP/SL children are dropped. A reduce-only order cannot carry protection orders, so the normalTpsl children prepared with the parent are removed at conversion time. Re-arm the protection on the resulting position yourself.

The action response does not report the conversion — its statuses carry one entry for the whole action, not per-order results. Read reduceOnly back from frontendOpenOrders (or historicalOrders once the order is terminal) to see the effective flag, and send r: true explicitly whenever reduce-only is what you actually want.

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.