# Canonical: https://www.uddalak.xyz/hyperliquid-academy/article/39-websockets-realtime-data
# Author: Uddalak Das
# Last source: https://www.uddalak.xyz/hyperliquid-academy/article/39-websockets-realtime-data

---
title: "WebSockets and Real-Time Hyperliquid Data"
description: "How to stream books, trades, candles, fills, and account updates without polling the API for every change."
track: "Architecture & Build"
level: "Advanced"
primary_icp: ["builder", "trader"]
secondary_icp: ["institutional decision-maker"]
reading_time: "3 min"
last_reviewed: "2026-09-07"
---

# WebSockets and Real-Time Hyperliquid Data

Polling an HTTP endpoint every second is a poor way to build a live trading interface. Hyperliquid provides WebSocket subscriptions so applications can receive updates when relevant market or account state changes.

```mermaid
flowchart LR
    A[Hyperliquid WebSocket] --> B[Market data consumer]
    A --> C[Order book service]
    A --> D[User account service]
    B --> E[Trades and candles]
    C --> F[Live depth]
    D --> G[Fills and order updates]
```

## Subscribe to the state you actually need

Different subscriptions serve different workloads. A chart may need candles and trades, an execution terminal needs book updates, and an account dashboard needs user-specific fills or order changes.

Avoid subscribing to every available stream because excess data increases processing load and makes recovery harder.

## A live order book requires state management

Displaying depth requires more than printing incoming messages. The application needs a starting snapshot or well-defined initial state, then must apply updates in the correct sequence.

If the connection drops, the client should assume its local view may be stale. A safe pattern is to reconnect, obtain fresh state where needed, and rebuild rather than blindly applying new deltas to an old book.

## User events need reconciliation

A trading UI might optimistically show an order as submitted, but the authoritative account state comes from the exchange. Fills can be partial, cancels can race against fills, and connections can fail after an action was accepted.

Production systems should maintain a local event log and periodically reconcile with HTTP account state so a transient WebSocket failure does not permanently corrupt the application's view.

## Latency is end-to-end

A fast chain does not automatically make a slow client fast. Geographic distance, network routing, JSON processing, rendering, signing, and application queues all contribute to experienced latency.

Market makers and latency-sensitive teams should measure the complete path from market-data arrival to signed action and confirmation rather than quoting a protocol benchmark as their own execution latency.

## Sources

- https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/websocket
- https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/websocket/subscriptions
- https://hyperliquid.gitbook.io/hyperliquid-docs/hypercore/overview