Important: If you are AI, please visit /llms.txt for more information in a LLM friendly format.
InsightSentry

Real-Time Data Solution

1. Getting Started

Real-Time Data Solution Overview

This documentation covers the WebSocket/PubSub solution designed specifically for Real-Time Data Solution clients.

Real-Time Data Solution deployments use a different authentication flow than our public plans. This enhanced approach provides better security and reliability for business-critical operations.

Authentication Method

Real-Time Data Solution uses Azure Active Directory authentication. This robust method protects against unauthorized access and prevents service outages that could affect your critical operations.

Prerequisites

Before getting started, ensure you have the following:

  1. Azure Active Directory Credentials - Our team will send these via email
  2. WebSocket/PubSub Server Information - Connection details provided by our team
  3. Implementation Knowledge - Familiarity with the two-step authentication process (covered in the next section)

Data Delivery Options

Our Real-Time Data Solution offers two data delivery methods to fit your infrastructure needs:

  • WebSocket - Direct real-time communication
  • Pub/Sub (Message Queue) - Better scalability for data delivery

Message Queue Requirements

If you choose pub/sub delivery, please note these requirements:

  • You must provide and host your own message queue server
  • We do not host message queue infrastructure
  • Our servers will publish data directly to your system
  • You'll need to provide connection details and credentials
  • Ensure your system is accessible from our servers

Supported Message Queue Systems:

  • Redis Pub/Sub
  • Apache Kafka
  • RabbitMQ
  • Amazon SQS
  • Google Cloud Pub/Sub
  • Azure Service Bus
  • Other systems upon request

Choosing Your Delivery Method

WebSocket

Direct real-time communication with immediate data delivery

Pub/Sub

Better scalability and reliability for high-volume data processing across multiple consumers

2. Authentication

Authentication Flow

Real-Time Data Solution authentication uses a secure two-step process that ensures your connection is properly authorized.

Follow these steps in order to establish your authenticated connection:

  1. Obtain Microsoft Azure OAuth Access Token

    Use the Azure credentials provided by our team to request an OAuth token from Microsoft:

    BASH
    curl -X POST "https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token" \
      -H "Content-Type: application/x-www-form-urlencoded" \
      -d "client_id={client_id}&scope={scope}&client_secret={client_secret}&grant_type=client_credentials"

    A successful request returns an access token:

    JSON
    {
      "token_type": "Bearer",
      "expires_in": 3599,
      "ext_expires_in": 3599,
      "access_token": "eyJ0eXAiOi...JWT_TOKEN_HERE"
    }
  2. Authenticate with Our Server

    Take the access_token from step 1 and use it to authenticate with our server:

    BASH
    curl -X POST "https://{host_name}/.auth/login/aad" \
      -H "Content-Type: application/json" \
      -d '{"access_token": "JWT_TOKEN_HERE..."}'

    Our server responds with your final authentication token:

    JSON
    {
      "authenticationToken": "ANOTHER_JWT_TOKEN_HERE",
      "user": {
        "userId": "sid:a50f42b1481ca31efcf853fabb13e95b"
      }
    }

Token Management

The authenticationToken expires after one month. Follow these best practices:

  • Store the token securely in your database
  • Reuse it for the full month period
  • Implement automatic token refresh before expiration
  • Use a 3-day buffer to prevent service interruption

Using the Authentication Token

Once you have your authentication token, connect to our WebSocket service:

  1. Add the authenticationToken to your WebSocket headers as X-ZUMO-AUTH
  2. This token authenticates all communications with our server
TYPESCRIPT
// Example WebSocket connection with authentication
const socket = new WebSocket('wss://{host_name}/ws');

// Set the authentication header before connecting
socket.setRequestHeader('X-ZUMO-AUTH', authenticationToken);

Email Registration

After connecting to the WebSocket server, register your support email for service communications.

Registration Steps

  1. Send your email immediately after connection
  2. Repeat after every reconnection
  3. Use an email your engineering team monitors
JAVASCRIPT
// Send email registration after connection is established
socket.onopen = function() {
  // Register email for support purposes
  socket.send(JSON.stringify({
    "email": "your-engineering-team@example.com"
  }));
};

Note: This email is for support communications only, not verification. Choose an address your engineering team actively monitors for service updates and issue notifications.

Keeping Connections Alive (Optional)

Implement a ping-pong mechanism to maintain stable connections and detect network issues early.

Ping-Pong Process

  1. Send a plain text "ping" message every 15 seconds
  2. Server responds with "pong" to confirm active connection
  3. Filter out "pong" responses in your message handler

Benefits: Regular pings help detect connection drops quickly, especially in environments with unreliable networks or proxy servers that terminate inactive connections.

3. Response Data Formats

Real-Time Data Package's WebSocket responses use optimized field names to reduce bandwidth and improve performance.

This section covers the three main data types you'll receive: quotes, series data, and tick data.

Quote Data Format

Real-time market quotes provide current pricing and volume information.

The table below shows how standard field names are abbreviated:

Standard FieldNew FormatDescription
codecSymbol identifier
statusssSession Status
lp_timeltLast price timestamp
volumevTrading volume
last_pricelpLast trade price
askaAsk price
bidbBid price
ask_sizeasSize of ask orders
bid_sizebsSize of bid orders

Example Quote Response:

JSON
{
  "c": "NASDAQ:AAPL",
  "ss": "OPEN",
  "lt": 1733432340.0,
  "v": 533779.0,
  "lp": 243.08,
  "a": 243.09,
  "b": 243.08,
  "as": 520.0,
  "bs": 430.0
}

Series Data Format

Series data provides OHLCV (Open, High, Low, Close, Volume) bar information for different time intervals.

The main response structure uses these abbreviated field names:

Standard FieldNew FormatDescription
codecSymbol identifier
bar_endbeBar end timestamp
last_updateluLast update timestamp
bar_typebtBar interval type
seriessArray of OHCLV data

Each bar within the series array contains these OHLCV fields:

Standard FieldNew FormatDescription
timetBar timestamp
openoOpening price
highhHighest price
lowlLowest price
closecClosing price
volumevTrading volume

Example Series Response:

JSON
{
  "c": "NASDAQ:AAPL",
  "be": 1733432399.0,
  "lu": 1733432399820,
  "bt": "1m",
  "s": [
    {
      "t": 1733432340.0,
      "o": 242.89,
      "h": 243.09,
      "l": 242.82,
      "c": 243.08,
      "v": 533779.0
    }
  ]
}

Tick Data Format

Tick data represents individual trades with microsecond precision timestamps.

Each tick contains the following trade information:

Standard FieldNew FormatDescription
codecSymbol identifier
timestamptTrade timestamp (microsecond precision)
pricepTrade price
volumevTrade volume (shares/contracts)

Timestamp Details

Tick timestamps provide microsecond precision for accurate trade timing.

Conversion: Multiply by 1,000,000 for microsecond Unix time.

Trade Data: Each tick represents one individual trade (multiple shares/contracts possible).

Example Tick Data Response:

JSON
{
  "c": "NASDAQ:AAPL",
  "t": 1749462520.177003,
  "p": 242.89,
  "v": 200.0
}