WebSocket API — Orders Channel

Live order lifecycle events for the authenticated account. Subscribe once; the server sends a snapshot of all live orders, then a stream of incremental updates.

wss://api.godarkdex.com/ws/v1

Authenticate with op: login first (see WebSocket Trading).

{ "id": "c-2", "op": "subscribe", "args": { "channel": "orders" } }

Response:

{ "id": "c-2", "op": "subscribe", "code": 0, "data": { "channel": "orders", "seq_start": 1 } }

Event Flow

snapshot → snapshot → ... → snapshot (snapshot_complete: true) → update → update → ...

The server first replays every currently live order as a snapshot frame, then emits update frames as state changes. The final snapshot frame carries snapshot_complete: true; that is the signal to start applying buffered updates.

Incremental updates that arrive while snapshot delivery is in progress should be buffered and replayed after snapshot_complete: true.

Frame Shape

Every frame on this channel:

{
  "channel": "orders",
  "type": "snapshot" | "update",
  "seq": 42,
  "snapshot_complete": false,
  "data": { /* order object — fields below */ }
}

Field	Description
`type`	`snapshot` during initial replay; `update` afterward
`seq`	Monotonic per subscription per session. Gaps mean a missed event.
`snapshot_complete`	`true` on the final snapshot frame; `false` on all others
`data`	The order object — see field reference below

Order Object

Same schema as GET /orders/{orderId}, plus a message_type that classifies the event:

`message_type`	Triggered when
`open`	Order accepted and working in the book
`partial_fill`	Order partially filled; remainder working
`filled`	Order fully filled
`cancelled`	Order cancelled (see `cancel_reason`)
`rejected`	Order rejected (see `reject_reason`)
`modified`	Modify applied
`cancel_rejected`	Cancel request failed (e.g. order no longer live)
`modify_rejected`	Modify request failed

Example — `update` / `filled`

{
  "channel": "orders",
  "type": "update",
  "seq": 128,
  "snapshot_complete": false,
  "data": {
    "message_type": "filled",
    "order_id": "ord_01HXYZ12345",
    "client_order_id": "my-order-001",
    "symbol": "BTC-USDC-PERP",
    "side": "buy",
    "type": "limit",
    "time_in_force": "GTC",
    "price": 95000,
    "quantity": 0.1,
    "filled_quantity": 0.1,
    "remaining_quantity": 0,
    "average_fill_price": 94998.5,
    "last_fill_qty": 0.07,
    "last_fill_price": 94998.0,
    "status": "FILLED",
    "in_time_ns": 1839975000775731091,
    "out_time_ns": 1839975000799293016,
    "cancel_reason": null,
    "reject_reason": null
  }
}

Field Reference

Field	Type	Description
`message_type`	string	See table above
`order_id`	string	Venue order id
`client_order_id`	string \| null	Idempotency key set on placement
`symbol`	string	Instrument id
`side`	string	`buy` or `sell`
`type`	string	`market`, `limit`, or `peg`
`time_in_force`	string	`GTC`, `GTT`, `IOC`, or `FOK`
`price`	number \| null	Limit price
`quantity`	number	Original order size
`filled_quantity`	number	Total filled so far
`remaining_quantity`	number	Unfilled remainder
`average_fill_price`	number \| null	Volume-weighted average
`last_fill_qty`	number \| null	Size of the fill in this event
`last_fill_price`	number \| null	Price of the fill in this event
`status`	string	`NEW`, `PARTIALLY_FILLED`, `FILLED`, `CANCELLED`, `REJECTED`
`in_time_ns`	integer	Order entry timestamp (ns epoch)
`out_time_ns`	integer	Event emit timestamp (ns epoch)
`cancel_reason`	string \| null	Populated on `cancelled`; see below
`reject_reason`	string \| null	Populated on `rejected` / `cancel_rejected` / `modify_rejected`; see below

Rejection Reasons

Values for reject_reason when message_type is rejected:

Value	Description
`MARGIN_INSUFFICIENT`	Pre-trade margin check failed
`POSITION_LIMIT_EXCEEDED`	Would exceed max position size
`LEVERAGE_EXCEEDED`	Requested leverage above instrument max
`INSUFFICIENT_LIQUIDITY`	FOK order could not be fully filled
`INVALID_PRICE`	Price outside acceptable range
`DUPLICATE_CLIENT_ORDER_ID`	Another live order uses this `client_order_id`
`INSTRUMENT_HALTED`	Instrument not currently accepting orders
`ACCOUNT_IN_LIQUIDATION`	Account is being liquidated; new orders blocked
`RISK_CHECK_FAILED`	Generic risk check failure

Cancellation Reasons

Values for cancel_reason when message_type is cancelled:

Value	Description
`USER_REQUESTED`	Cancelled by user via REST or WS
`IOC_REMAINDER`	Unfilled portion of an IOC order
`FOK_NOT_FILLED`	FOK order could not fully fill
`GTT_EXPIRED`	Reached `expiry_time`
`SELF_TRADE_PREVENTION`	Would have matched against the same account
`LIQUIDATION`	Account entered liquidation
`CANCEL_ON_DISCONNECT`	Socket disconnected with `cancel_on_disconnect: true`
`SYSTEM_CANCEL`	Cancelled by the system (settlement, cluster migration, etc.)

Gap Recovery

Clients should track seq. If a gap appears (seq_n > seq_{n-1} + 1):

op: unsubscribe { channel: "orders" }
op: subscribe { channel: "orders" } — receive a fresh snapshot
Resume applying updates from the new seq series

Unsubscribe

{ "id": "c-9", "op": "unsubscribe", "args": { "channel": "orders" } }