Crypto Trade Event Push Overview

The WebSocket crypto trade event push delivers real-time account-level trade event notifications once a connection is established and authentication is complete. It is well-suited for time-sensitive scenarios such as order status changes and fill notifications.

WebSocket Trade endpoint:

wss://webapi-trade.futunn.com/ws

Capabilities

Event Type	Description
EVENT_NEW	Order placement succeeded. The order has been accepted by the system and entered the order queue.
EVENT_NEW_REJECTED	Order placement failed. The order was rejected by the system (e.g. insufficient balance, invalid price, risk control block).
EVENT_FILL	Fill event. Includes both partial fills and full fills. Use order_info.ord_status and order_info.is_close to distinguish between them.
EVENT_CANCELED	Order cancellation succeeded. The order has been fully cancelled and reached a terminal state.
EVENT_EXPIRED	Order expired. The order was cancelled by the system due to expiry and reached a terminal state.

For the complete field descriptions of push messages, see Data Format.

Integration Steps

Step	Description
1. Establish Connection	Connect to the WebSocket Trade endpoint wss://webapi-trade.futunn.com/ws.
2. Authenticate	Complete login authentication after the connection is established. OAuth 2.1 + PKCE Bearer Token is recommended; traditional API Key is also supported. See Authentication.
3. Receive Push Events	After successful authentication, you will automatically receive all crypto trade events for the authenticated user — no additional subscription request is needed. The server pushes Protobuf binary messages when trade events occur. See Subscription.
4. Keep Connection Alive	Periodically refresh the token to maintain connection validity and prevent disconnection due to token expiry. See Connection Keep-Alive.
5. Reconnect on Disconnect	If the connection drops, the client should reconnect and re-authenticate. Event push resumes automatically after reconnection. Do not assume that events missed during the disconnect will be replayed.

Important Constraints

• Authentication required first: No events will be pushed until login authentication is complete.
• No replay guarantee: Trade events that occurred during a disconnection will not be replayed after reconnection. Use REST endpoints to retrieve historical order or fill data if needed.
• Long connections require fault tolerance: Network switches, proxy timeouts, and server maintenance can all cause disconnections. The client should implement reconnection and re-authentication logic.
• Event order is not strictly guaranteed: In rare cases, network jitter may cause events to arrive out of order relative to when they actually occurred. Do not rely solely on push order as the state machine driver.

Next Steps

• Authentication — Learn the login authentication flow after establishing a WebSocket connection.
• Subscription & Event Handling — Event types, terminal state detection, idempotency recommendations, and timing examples.
• Connection Keep-Alive — Heartbeat, timeout, and reconnection handling for long-lived connections.
• Data Format — Push message structure, event types, and field descriptions.
• Error Codes — Troubleshoot authentication and connection errors.