User Orders - SOAR Trading API

A prediction-order message is sent when one of your orders changes state — accepted, partially filled, filled, cancelled or expired.

Access

Requires an API key with the read scope. Send an authenticate frame; there is no separate subscribe for the private stream.

Fields

Field	Type	Description
`type`	string	Always `"prediction-order"`
`orderId`	string	Your order’s id. Always treat as a string
`eventMarketId`	string	UUID of the market
`status`	string	Current order state — see below
`side`	string?	`"buy"` or `"sell"`
`outcome`	string?	`"yes"` or `"no"`
`price`	number?	The order’s original limit price, in cents
`filledQty`	number?	Shares filled so far
`remainingQty`	number?	Shares still resting
`cancelReason`	string?	Why the order was cancelled, when applicable
`ts`	number	Unix timestamp in nanoseconds

As on fills, orderId is a string carrying a 63-bit value. Do not parse it as a number.

Status values

`status`	Meaning
`accepted`	The engine has sequenced the order
`open`	Resting on the book
`partially_filled`	Some quantity filled, the rest still resting
`filled`	Fully filled
`canceled`	Cancelled — check `cancelReason`
`expired`	Expired without fully filling

cancelReason is replaced when the order was cancelled as part of an amend: amending replaces the resting order, so you receive a cancellation for the old order id alongside the new one.

price is the order’s original limit price, not an execution price. For what you actually paid, read fillPrice on the corresponding fill.

Example

{
  "type": "prediction-market-update",
  "data": {
    "type": "prediction-order",
    "orderId": "7284619305827364910",
    "eventMarketId": "9f1c2d3e-4a5b-6c7d-8e9f-0a1b2c3d4e5f",
    "status": "partially_filled",
    "side": "buy",
    "outcome": "yes",
    "price": 62,
    "filledQty": 40,
    "remainingQty": 60,
    "ts": 1789238400123456789
  }
}

Notes

status is the durable answer. The REST create-order response always returns the literal "accepted" regardless of fill state — it tells you the engine sequenced your command, not what happened to it. The socket tells you what happened.
The optional fields are populated on engine-emitted updates. Treat them as optional anyway and fall back to your own record of the order rather than assuming presence.
This replaces polling GET /v1/orders/{order_id}.