Subscription

Trade event push uses a connect-and-subscribe model: once the client establishes a WebSocket connection and completes authentication, the server automatically pushes trade events for the authenticated user — no explicit subscription request is needed.

Difference from Quote Push

Quote push requires the client to explicitly declare which instruments and data types to subscribe to. Trade push works differently:

Dimension	Quote Push	Trade Push
Subscription method	Explicit — specify instrument code and data type	Implicit — takes effect automatically after authentication
Push scope	Only subscribed instruments and types	All event types for all accounts under the authenticated user
Unsubscribe	Unsubscribe at any time	Disconnect to stop receiving

Event Coverage

After authentication succeeds, the client automatically receives all of the following event types. Individual event types cannot be filtered out:

Event Type	Description
EVENT_NEW	Order placed successfully
EVENT_REPLACED	Order modified successfully
EVENT_CANCELED	Order cancelled successfully
EVENT_EXPIRED	Order expired
EVENT_FILL	Fill event (partial fill or full fill)
EVENT_NEW_REJECTED	Order placement rejected
EVENT_REPLACE_REJECTED	Order modification rejected
EVENT_CANCEL_REJECTED	Order cancellation rejected
EVENT_FILL_CORRECT	Fill correction
EVENT_FILL_CANCEL	Fill cancellation

See Data Format for the full message structure and field reference for each event.

Account Scope

The server pushes events at the account level of the authenticated user — events for all trading accounts under that user are included. The user_info.acc_id field in each push message identifies the specific trading account the event belongs to. If the same user holds multiple trading accounts, events from all accounts are pushed on the same connection. Clients should use acc_id to distinguish the source.

Behavior

When Events Are Pushed

The server pushes events in real time when trade events occur. Delivery time depends on network conditions and server-side processing latency — a fixed push interval is not guaranteed.

No Replay of Historical Events

Trade events that occur while the connection is down will not be replayed after reconnection. To query historical orders or fills, use the following REST APIs:

• Get Today's Orders — Query today's orders.
• Get Today's Fills — Query today's fill records.
• Get Historical Orders — Query historical orders.
• Get Historical Fills — Query historical fill records.

Recovery After Reconnection

After the connection drops and authentication is completed again, the server automatically re-establishes the push channel and continues pushing subsequent events.

Client Implementation Recommendations

• Do not rely on push as the sole source of state: Push is suitable for real-time notifications. For the initial page load or catching up after a disconnect, call REST APIs first to query the complete state.
• Handle duplicate events: In rare network jitter or server retry scenarios, duplicate event pushes may be received. Clients should implement idempotent handling keyed on event_id.
• Do not rely on event order: Network jitter may cause events to arrive out of order. To reconstruct state, use fields such as order_status and event_time_us within each event rather than relying on push order.

Next Steps

• Authentication — Learn about the authentication flow.
• Keep Alive — Handle disconnections and reconnections.
• Data Format — View the full field reference for event messages.