# Canonical: https://www.uddalak.xyz/hyperliquid-academy/article/91-rest-vs-websocket-on-hyperliquid
# Author: Uddalak Das
# Last source: https://www.uddalak.xyz/hyperliquid-academy/article/91-rest-vs-websocket-on-hyperliquid

---
title: "REST vs WebSocket on Hyperliquid"
description: "Use REST for snapshots, metadata, and action submission where appropriate; use WebSockets for continuously changing market and account state that would be wasteful or slow to poll."
pillar: "Architecture & Build"
track: "Architecture & Build"
cluster: "Architecture & Build"
level: "Intermediate"
primary_icp: ["builder", "trader"]
secondary_icp: []
content_type: "comparison"
reading_time: "3 min"
last_reviewed: "2026-09-07"
last_verified: "2026-09-07"
volatile: true
prerequisites: ["39-websockets-realtime-data"]
related: ["90-hyperliquid-api-rate-limits", "94-production-grade-hyperliquid-trading-bot"]
---

# REST vs WebSocket on Hyperliquid

REST and WebSocket solve different problems in a Hyperliquid integration. REST gives explicit request-response snapshots and exchange actions. WebSockets keep a long-lived connection that pushes subscribed updates such as books, trades, fills, orders, and account changes. A robust trading application normally uses both rather than choosing one universally.

## REST strengths

REST is simple to inspect, retry, cache, and use for low-frequency state. It is appropriate for metadata, one-off account queries, historical windows, and exchange action submission through documented endpoints.

Its cost grows quickly if a client repeatedly asks for state that changes many times per second.

## WebSocket strengths

A WebSocket subscription lets the server push updates as they occur. That reduces request overhead and latency for order books, trades, fills, order updates, candles, and other supported streams.

The client must handle lifecycle complexity: disconnects, reconnects, resubscription, duplicate or missed state, and heartbeat/timeout behavior.

## Snapshot plus stream

The safest pattern for mutable state is often: fetch a known snapshot, establish or confirm the stream, then apply incremental updates with sequence or reconciliation logic appropriate to that feed.

After a disconnect, do not blindly assume the local book or position cache remains complete. Rebuild from an authoritative snapshot when required.

## Rate-limit implications

Polling an L2 book every few milliseconds burns REST weight unnecessarily. A stream is designed for that workload. Conversely, maintaining hundreds of sockets for data that changes once per hour is needless complexity.

Choose the transport from the state-change frequency and correctness requirements.

## How this connects

Start with [WebSockets and Real-Time Hyperliquid Data](/hyperliquid-academy/article/39-websockets-realtime-data) if the underlying concept is unfamiliar. Related reading: [Hyperliquid API Rate Limits Explained](/hyperliquid-academy/article/90-hyperliquid-api-rate-limits), [How to Build a Production-Grade Hyperliquid Trading Bot](/hyperliquid-academy/article/94-production-grade-hyperliquid-trading-bot).

## 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/for-developers/api/info-endpoint
- https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/rate-limits-and-user-limits