Hyperliquid WebSocket Subscription Limits: What They Mean for Your Trading Infrastructure

You need trade data for every market on Hyperliquid. You write a subscription message, expecting to pass an array of coins and receive aggregated updates. Instead: silence. No error, no data - the API simply ignores your request.

Hyperliquid's WebSocket API does not support batch subscriptions. Each trading pair requires its own subscription message. With a hard limit of 1,000 subscriptions per IP address and 239+ perpetual markets (growing daily thanks to HIP-3 permissionless listings), developers quickly discover that full market coverage becomes mathematically challenging for comprehensive use cases.

This article explains the limits, what they mean for different applications, and how Dwellir's infrastructure removes these constraints entirely.

No Batch Subscriptions

Hyperliquid does not support batch WebSocket subscriptions. You cannot subscribe to multiple markets in a single message. Each subscription must target a single market:

{
  "method": "subscribe",
  "subscription": {
    "type": "trades",
    "coin": "BTC"
  }
}

Monitoring trade data for 50 markets requires 50 separate subscription messages. Add L2 order book data for those same markets and you need 100 subscriptions. Include candle data across multiple timeframes and the count escalates quickly.

WebSocket Rate Limits

Hyperliquid enforces three rate limits on WebSocket connections:

The subscription limit applies across all WebSocket connections from your IP address. Opening 10 connections does not give you 10,000 subscriptions - you still have 1,000 total. The connection limit prevents server resource exhaustion, while the message rate limit governs how quickly you can subscribe, unsubscribe, and manage your feeds.

For more on Hyperliquid's architecture and how these limits fit into the broader infrastructure picture, see What Is Hyperliquid?.

Subscription Types

Hyperliquid supports 19 WebSocket subscription types:

Most subscription types require a coin parameter, meaning each market-subscription combination consumes one slot from your 1,000 allocation.

The Exception: allMids

The allMids subscription is the only aggregated feed available. A single subscription delivers mid prices for every market on Hyperliquid. For applications that only need price data (portfolio trackers, price alerts, cross-market correlation analysis), allMids provides complete coverage in a single subscription. It does not include trade data, order book depth, or candle information.

Subscription Math: Where the Limits Bite

Consider a market-making operation that needs trades and L2 order book data for all perpetual markets:

This fits within the 1,000 limit. But add candle data for backtesting signals:

You now exceed the limit by 43%. This calculation assumes the market count stays at 239. With HIP-3 enabling permissionless market creation, new trading pairs launch regularly. A system designed around current market counts will break as the ecosystem grows.

For analytics platforms monitoring all data types across all markets, the numbers become more challenging:

• 239 markets x 3 core data types (trades, l2Book, candle) = 717 subscriptions minimum
• Add multiple candle timeframes and the count doubles
• Include BBO for latency-sensitive applications and it climbs further

The 1,000-subscription ceiling cannot accommodate comprehensive market coverage from a single IP.

The DIY Approach: Trade-offs

Developers facing these limits typically consider several workarounds:

Market prioritization - Subscribe only to high-volume pairs and rotate through others periodically. This works for focused applications but means gaps in coverage and potential missed opportunities in emerging markets.

Multi-IP distribution - Spread subscriptions across multiple servers with different IP addresses. This requires coordination infrastructure, increases complexity, and multiplies hosting costs.

REST polling - Supplement WebSocket feeds with periodic REST API calls for less time-sensitive data. This adds latency and consumes REST rate limit quota (1,200 requests per minute).

Each approach involves trade-offs between coverage, latency, complexity, and cost. For teams building production trading systems, managing these workarounds becomes a distraction from core product development.

Dwellir Infrastructure: No Subscription Limits

For professional trading operations, Dwellir's infrastructure removes the subscription ceiling entirely. Rather than managing workarounds, you receive aggregated market data through optimized channels.

Order Book Server

Dwellir's Order Book Server provides:

• Full market coverage - All markets, all data types, no subscription management
• L4 order book access - Individual order visibility with user addresses, enabling order flow analysis and liquidity mapping unavailable through the public API
• Automatic state recovery - Reconnection handling and data continuity without client-side complexity
• Lower latency - Benchmarks show a 24.1% median latency improvement (51ms faster) compared to the public feed

For implementation details, see How to Use the Hyperliquid Order Book Server.

gRPC Streaming

Dwellir's gRPC endpoints deliver market data with protocol-level efficiency advantages over WebSocket:

• Binary serialization - Smaller message sizes, faster parsing
• Multiplexed streams - Multiple data feeds over a single connection
• Built-in compression - Reduced bandwidth requirements
• Typed contracts - Strongly-typed message definitions eliminate parsing errors

gRPC is particularly suited for high-frequency applications where every millisecond matters.

When Managed Infrastructure Makes Sense

Consider Dwellir's infrastructure when:

Your subscription math exceeds 1,000. If you need trades, L2 order books, and candle data across all markets, no amount of optimization will fit within public limits.

You need L4 order book data. The public API provides only L2 aggregated depth. L4 data shows individual orders with user addresses - this data is only available through authenticated infrastructure. Learn more in 5x More Market Depth with Dwellir's Order Book Server.

Latency matters. Public WebSocket infrastructure experiences variable performance based on network load. For time-sensitive trading strategies, consistent low-latency feeds provide measurable edge.

Reliability is non-negotiable. Production trading systems need guaranteed uptime and automatic failover. Public endpoints offer no SLAs.

You want to focus on trading, not infrastructure. Managing multi-IP coordination, handling reconnection logic, and aggregating data across connections is engineering effort that could go toward your core product.

For a broader comparison of infrastructure options, from public RPC to dedicated nodes and co-location, see Hyperliquid Endpoint Options Beyond Public RPC.

Monitoring Your Subscription Usage

If you're working within the public limits, track these metrics:

High subscription churn can indicate inefficient rotation strategies or bugs in subscription management. Approaching the 900-subscription mark signals it's time to consider infrastructure alternatives.

Summary

Hyperliquid's WebSocket API does not support batch subscriptions. Each market-data-type combination requires an individual subscription, subject to a 1,000-subscription-per-IP limit. For applications requiring comprehensive market coverage - which increasingly means most serious trading operations - these limits create real constraints.

The key question is whether managing those constraints is the best use of your engineering resources. DIY approaches work for focused applications with limited market coverage requirements. For operations that need full market data, lower latency, or L4 order book depth, Dwellir's infrastructure converts an ongoing infrastructure problem into a service that scales with your needs.

For teams building on Hyperliquid who need full market coverage: explore the Order Book Server documentation, review the gRPC streaming options, or contact the Dwellir team to discuss your infrastructure needs.