Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
| developers:websocket [2025/03/14 03:02] – external edit 127.0.0.1 | developers:websocket [2025/03/14 19:15] (current) – [Message Structure Overview] chad | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Getting Started ====== | + | ===== WebSocket API Introduction |
| - | To begin integrating, visit the [[getting_started|Getting Started]] guide for **connection | + | The WebSocket API provides a high-performance, low-latency communication channel for real-time trading data and order execution. This section introduces |
| + | |||
| + | ==== WebSockets ==== | ||
| + | WebSockets establish a persistent, full-duplex connection between the client and server, allowing | ||
| + | |||
| + | **Key Advantages: | ||
| + | * Persistent | ||
| + | * Low-latency, real-time data exchange | ||
| + | * Efficient bandwidth usage compared to REST APIs | ||
| + | |||
| + | ==== Google Protocol Buffers (Protobuf) ==== | ||
| + | The API utilizes Protobuf for efficient, compact, and high-speed message serialization. Unlike JSON or XML, Protobuf messages are smaller and faster to parse, making them well-suited for high-frequency trading applications. | ||
| + | |||
| + | **Why Protobuf? | ||
| + | * **Compact Encoding:** Reduces message size for faster transmission | ||
| + | * **High Performance: | ||
| + | * **Schema Evolution: | ||
| + | |||
| + | ==== Communication Model ==== | ||
| + | The API follows a structured messaging approach: | ||
| + | * **Client Messages:** Requests sent from clients to the server (e.g., order submission, subscription requests) | ||
| + | * **Server Messages:** Responses and real-time updates sent from the server (e.g., trade confirmations, | ||
| + | |||
| + | ==== Message Structure Overview ==== | ||
| + | |||
| + | All messages sent to the server must be wrapped in a **ClientMessage** envelope, and all messages received from the server will be contained within a **ServerMessage** envelope. This ensures a consistent structure and simplifies message parsing. | ||
| + | |||
| + | === Client Message Structure === | ||
| + | |||
| + | A **ClientMessage** is the top-level wrapper for all messages sent to the server. It contains fields for various message types, such as authentication | ||
| + | |||
| + | Example | ||
| + | |||
| + | < | ||
| + | message ClientMessage { | ||
| + | oneof payload { | ||
| + | AuthenticationRequest authentication_request = 1; | ||
| + | MarketSubscription market_subscription = 2; | ||
| + | OrderRequest order_request = 3; | ||
| + | // ... other client messages | ||
| + | } | ||
| + | } | ||
| + | </ | ||
| + | |||
| + | === Server Message Structure === | ||
| + | |||
| + | A **ServerMessage** is the top-level wrapper for all responses and updates from the server. It encapsulates messages related to market data, account updates, and execution reports. | ||
| + | |||
| + | Example **ServerMessage**: | ||
| + | |||
| + | < | ||
| + | message ServerMessage { | ||
| + | oneof payload { | ||
| + | AuthenticationResponse authentication_response = 1; | ||
| + | MarketSnapshot market_snapshot = 2; | ||
| + | OrderUpdate order_update = 3; | ||
| + | // ... other server messages | ||
| + | } | ||
| + | } | ||
| + | </ | ||
| + | |||
| + | |||
| + | === Message Tools === | ||
| + | |||
| + | The [[https:// | ||
| + | |||
| + | < | ||
| + | Reach out to support if you would like a API tool's for a language we have not covered yet. | ||
| + | </ | ||
| + | |||
| + | ^ **Platform** ^ **Client Message Helper** ^ | ||
| + | | **.Net** | [[https:// | ||
| - | For a detailed breakdown of all available messages, see the [[message_reference|Message Reference]]. | ||
| - | ---- | ||
| - | 💡 **Tip:** Use WebSocket clients like `wscat` or our sample SDKs to test the API before building your integration. | ||
| - | ===== Next Steps ===== | ||
| - | * Connect and Authenticate to **market data streams** ([[api: | ||