Hello, Issue on
— the
/v2/stream/{streamId}
WebSocket pushes
Orders
frames for every stage of an order’s lifecycle (new, modify, cancel, fill), but the
st
field is always
0
(NEW). Actual state transitions never show up in the stream.
Reproducible sequence
(single order, watched on a live WS feed): 1. POST
/orders
→ HTTP 200 → WS emits
Orders
frame with
st: 0
✓ 2. PATCH
/orders/{id}
(modify limit price) → HTTP 200, REST confirms new price → WS emits
Orders
frames (sometimes for replacement ids), all
st: 0
- DELETE
/orders/{id}
→ HTTP 200, REST
/orders/{account}/Any
now shows
status: “CANCELLED”
→ WS emits more
Orders
frames for the same
oid
, still
st: 0
, never
st: 4
- Fill (partial or full) → REST shows
status: “FILLED”
→ WS
st
stays
0
So a client connected only to the WebSocket has no way to distinguish between: - an order that was just placed - an order that was modified - an order that was cancelled - an order that was filled They all look identical: repeated
Orders
frames with
st: 0
.
Questions
- Is the WS supposed to emit the transitioned
st
value (e.g.
st: 4
on cancel,
st: 2
on fill) and this is a bug on
/v2/stream
? - Or is REST polling (
/orders?status=Any
) the only authoritative source for lifecycle transitions by design? - Other threads on this forum around MQTT / C# suggest these events
do
come through on those transports — so is this a gap specific to the WebSocket? Right now the only reliable way to track order state is a 1 Hz REST reconciler against
/orders
, which adds latency and REST traffic even with an active WS open.
Environment
, REST
/v2/
wss://live.ironbeamapi.com/v2/stream/{streamId}
- MES / MNQ front-month - Can share frame dumps / probe scripts if helpful Thanks.