Dealer request events¶
The server sends dealer request events directly to every active TCP session whose staff id belongs to the request's dealer pool. A session does not need to subscribe to a public channel, and requests from other pools are not broadcast to it.
Synchronization¶
After authorization or reconnection, call MngGetDealerRequests to obtain the current snapshot. Use events only for changes received after that snapshot; events are not a durable replacement for synchronization.
Event names¶
| Event | Type | Meaning |
|---|---|---|
dealer.request.created |
0 |
A new pending request was created. |
dealer.request.claimed |
1 |
A dealer claimed the request. |
dealer.request.released |
2 |
The assigned dealer returned it to the pool. |
dealer.request.executing |
3 |
Accepted execution started. |
dealer.request.completed |
4 |
Execution finished with EXECUTED or EXECUTION_FAILED. |
dealer.request.rejected |
5 |
The assigned dealer rejected the request. |
dealer.request.expired |
6 |
The request deadline expired. |
Payload¶
Every event contains the complete current request representation:
{
"event": "dealer.request.created",
"type": 0,
"version": 17,
"data": {
"id": 42,
"operation": 1,
"login": 10001,
"order": 70001,
"symbol": "EURUSD",
"cmd": 0,
"volume": 100,
"route_id": 1,
"route_step_position": 0,
"dealer_pool_id": 3,
"status": 0,
"assigned_dealer_login": 0,
"created_at": 1785300000,
"deadline_at": 1785300030,
"completed_at": 0,
"execution_result": 0,
"dealer_comment": ""
}
}
Pool membership determines whether the request belongs to the current dealer. For claimed requests, assigned_dealer_login identifies the dealer allowed to release, accept, or reject it.
When a request is rejected, the same domain event is also projected to the trading account's WebSocket connection using the standard compact trade event format. The event code is EV_RECORD_REJECT_TRADE. For an opening request, the trade state is TS_OPEN_REJECT; close and partial-close rejections preserve the existing position state.
version is a monotonically increasing dealer-request snapshot version. Event callbacks may be processed concurrently and events for different requests may arrive out of order.
After loading a snapshot, ignore every event with version <= snapshot_version. For newer events, track the last applied version separately for each request id and ignore only an older event for that same request. Do not use one global last-event version: gaps and reordering are valid because changes for other requests or dealer pools may be processed concurrently. After reconnecting, request a fresh snapshot.