> ## Documentation Index
> Fetch the complete documentation index at: https://docs.trysoar.com/llms.txt
> Use this file to discover all available pages before exploring further.

# User Orders

> State changes on your own orders.

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`](/websockets/connection) 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** |

<Warning>
  As on [fills](/websockets/user-fills#fields), `orderId` is a string carrying a
  63-bit value. Do not parse it as a number.
</Warning>

## 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.

<Note>
  `price` is the order's **original limit price**, not an execution price. For
  what you actually paid, read `fillPrice` on the corresponding
  [fill](/websockets/user-fills).
</Note>

## Example

```json theme={null}
{
  "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}`.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.