A Guide to Hyperliquid Data API vs. Streams

The Architecture of Hyperliquid Data Integration

Hyperliquid blockchain runs on two layers that work together. HyperCore is the trading engine; it handles the on-chain order books, perpetual futures, and spot markets with near-instant finality. HyperCore is a custom Rust-based L1 utilizing HyperBFT consensus to handle order-book operations with ~0.2-second finality. It manages the trading engine with 8-decimal precision. Alongside it, HyperEVM acts as the Ethereum-compatible layer (18-decimal precision) for smart contract composability, allowing developers to deploy Solidity-based dApps that interact seamlessly with HyperCore’s liquidity.

How Data Moves On Hyperliquid

Data access follows this same split. HyperCore provides trading data (prices, trades, order books, funding rates, liquidations) via its own endpoints. HyperEVM provides smart contract data via standard JSON-RPC methods, the same format used across Ethereum and its Layer 2s.

When people say “Hyperliquid Data API,” they mean the official REST and WebSocket endpoints you can hit directly. When they say “Streams,” they mean managed, push-based delivery systems, often accessed through a private gateway that sits on top of this infrastructure and handles the heavy lifting for you. Your Hyperliquid integration approach depends entirely on which model fits your use case.

Hyperliquid Data API: When Pulling Data Works Best

The official API is your simplest starting point. It’s free, well-documented, and doesn’t need any third-party accounts. The REST side works like a question-and-answer system. You send a request (“What are my open positions?” or “What’s ETH’s funding rate?”), and you get a JSON response back. There are over 50 query types covering everything from market metadata to trade history and candle charts.

How the Hyperliquid REST and WebSocket API Works

The WebSocket side handles real-time data. You open a persistent connection, subscribe to specific feeds—say, BTC trades or ETH order book updates—and the server pushes new data to you as it happens on-chain. It supports trades, order-book snapshots, best bid/offer, mid prices, candles, and user-specific feeds such as fills and funding payments.

For a personal trading tool, a price dashboard, or a basic bot watching a handful of assets, this covers everything you need.

Overcoming Subscription Caps and Scaling with HypeRPC

The catch? The public WebSocket caps you at 1,000 total subscriptions per IP address. Since each asset-feed combo (like “BTC trades” or “ETH order book”) counts as one subscription, monitoring many markets across multiple feed types eats through that limit fast. There are also rate limits on REST queries, and if your connection drops, you’re responsible for reconnecting and catching up on missed data.

For solo projects and moderate-scale applications, these limits rarely bite. For production systems that watch dozens or hundreds of markets, this becomes a real constraint. While the public API caps you at 100 requests per minute, HypeRPC elevates your throughput to 12,000 REST weight units and 20,000 WebSocket messages per minute, providing the 10x headroom necessary for high-frequency strategies.

Real-Time Streams: Mastering the Hyperliquid WebSocket and Beyond

Streams flip the whole model around. Instead of your app connecting to endpoints, managing subscriptions, handling disconnects, and filtering through everything client-side, a streaming service does all of that and delivers only what you asked for.

At the protocol level, HyperCore exposes seven native data stream types through gRPC: Trades, Orders, Book Updates, TWAP, Events, Blocks, and Writer Actions. That means smaller messages and faster processing compared to standard WebSocket feeds.

The biggest advantage is delivery guarantees. Streams provide exactly-once delivery: every event arrives once, in the right order, with no duplicates or gaps. Building this level of reliability with raw WebSocket connections and custom retry code is serious engineering work that most teams would rather skip.

Reduce your data overhead by 70% using native zstd binary compression. In a 24/7 production environment, this efficiency significantly lowers your bandwidth costs while allowing you to process more market-depth (L2/L4) updates without hitting local hardware bottlenecks.

Why HypeRPC Is the Preferred Private Gateway for Data

Public endpoints are shared infrastructure. When traffic spikes, so does your latency. A private gateway solves this, and that’s exactly what HypeRPC is.

Built specifically for the Hyperliquid ecosystem by Imperator, HypeRPC isn’t a Stream or a separate API. It’s a managed access layer that sits between your application and Hyperliquid’s native endpoints: essentially a 1:1 Data API Private Gateway. Colocate your strategy in Tokyo (JP) with HypeRPC to achieve the absolute lowest physical latency. By utilizing Direct Sentry Peering, your dedicated node bypasses public internet hops, giving you a raw, non-validator-speed line to the Hyperliquid chain.

The key distinction: you can use HypeRPC with both the Data API approach (REST + WebSocket) and Streams. It’s the infrastructure layer underneath, not a competing data method. For anyone moving from prototype to production, it’s usually the first upgrade that pays for itself.

HIP-4 and Beyond: Data Needs for Outcome Trading

Hyperliquid keeps expanding. HIP-4 Outcome Markets bring prediction-style YES/NO contracts to HyperCore. Think binary bets on real-world events, settled on-chain using USDH. This adds entirely new data types (contract creation, settlement triggers, outcome positions) that your app may need to consume alongside regular trading data.

If you’re on Streams, adding these is just another subscription. On raw WebSocket connections, each new feed type eats into your 1,000-slot cap. As Hyperliquid’s ecosystem grows with new asset types and market structures, choosing a data strategy that scales with it saves you from painful rewiring later.

Scaling Your Integration with a Private Hyperliquid Data API

Here’s the honest bottom line. Neither approach is universally “better”; the right choice maps to where you are right now and where you’re headed. Start with the free public Hyperliquid Data API. Use it to prototype and validate your idea. Community SDKs in Python, TypeScript, and Rust make this fast.

Best Hyperliquid Data Approach

Move to Streams when scale demands it. Once you’re watching many markets, feeding data into storage, or running anything where missed events cost real money, the reliability and filtering of Streams justify the cost. The engineering hours you save on connection management go straight into building what actually matters: your strategy, your product, your edge.

Layer in a private gateway like HypeRPC when consistency matters. Whether you’re using the Data API, Streams, or both, a dedicated gateway gives you the predictable latency and uptime that shared public endpoints simply cannot guarantee.

Most mature setups end up combining all three: Streams for bulk data ingestion and analytics, the native Hyperliquid Data API for quick queries and order placement, and HypeRPC underneath for reliable access across the board.