Hyperliquid API: REST vs WebSocket vs gRPC Compared

Disclosure: CoinCodeCap may earn a commission if you sign up for Hyperliquid through links on this page. Risk warning: Crypto trading and infrastructure decisions involve risk — always benchmark in your own environment before going to production.

How We Compare: CoinCodeCap evaluates Hyperliquid API mechanisms on six factors: latency profile, throughput ceiling, message delivery model (pull vs push), use-case fit (reads, writes, real-time, HFT), provider availability, and operational complexity. Endpoint URLs, rate limits, and subscription types are pulled directly from the official Hyperliquid docs at hyperliquid.gitbook.io.

The Hyperliquid API splits into three distinct mechanisms: REST for synchronous request/response, WebSocket for real-time push subscriptions, and gRPC streaming for high-frequency HyperCore data ingest. Picking the right one isn’t a “best wins” question — every production Hyperliquid bot uses at least two of them. The interesting question is which mechanism handles which workload, and where the boundaries between them sit.

Two non-negotiable facts up front. First: writes always go through REST at https://api.hyperliquid.xyz/exchange with ECDSA-signed payloads. There’s no alternative path — order placement, cancels, transfers, and vault actions all route through the official Exchange endpoint. Second: gRPC is provider-only. Hyperliquid’s core team doesn’t ship a public gRPC endpoint; if you need it, you go through Dwellir, QuickNode, or HypeRPC.

This guide compares the three Hyperliquid API mechanisms across latency, throughput, use cases, and provider support — with the goal of helping you pick the right combination for your bot or analytics pipeline. If you’re earlier in the build, see our Hyperliquid RPC providers comparison and bot frameworks guide for the full developer stack.

What to Look For When Picking Hyperliquid API Mechanisms

Six factors should drive your decision between REST, WebSocket, and gRPC for any specific workload:

• Read frequency: One-time reads (account state on bot startup, asset metadata) belong on REST. Continuous reads (live order book, trades) belong on WebSocket. High-frequency reads at HFT scale belong on gRPC.
• Write requirements: All writes route through REST /exchange. There’s no choice — the Exchange endpoint is signed-payload-only and accepts no alternatives.
• Subscription cap: WebSocket has a 1,000-subscription per-IP cap. If you’re tracking thousands of markets or wallets, you’ll either hit this ceiling or run multiple connections. Plan upfront.
• Snapshot semantics: WebSocket subscriptions deliver a snapshot first (isSnapshot: true) followed by streaming updates (isSnapshot: false). Bots that handle reconnections need to deduplicate state cleanly.
• Provider lock-in for gRPC: gRPC HyperCore data is only available through paid providers. Pick whether you want Dwellir’s L4 order book server, QuickNode’s seven unified streams, or HypeRPC’s validator-near routing.
• Reconnection behaviour: The official docs warn that disconnections happen periodically without announcement. Implement exponential-backoff reconnects for both WebSocket and gRPC. Missed data arrives in the snapshot ack on reconnect.

How to Choose: A Decision Tree by Workload

Match your specific workload to the right Hyperliquid API mechanism:

• Placing or cancelling orders? → REST /exchange. Always. No alternative exists.
• Fetching account balance, asset list, or one-shot metadata? → REST /info. Single request, return value, done.
• Tracking live trades, fills, order book, or funding rates for one or a few coins? → WebSocket. Free, push-based, snapshot + stream model.
• Tracking 1,000+ markets or 100+ user wallets simultaneously? → Multiple WebSocket connections OR gRPC streams. WebSocket subscription cap will become the binding constraint.
• Building HFT, market making, or latency arbitrage? → gRPC HyperCore streaming via Dwellir, QuickNode, or HypeRPC. Sub-second latency, 70+ blocks/sec processing.
• Need L4 individual order visibility (user addresses, order IDs, timestamps)? → Dwellir’s L4 order book server is currently the only managed option.
• Just learning or prototyping under 100 req/min? → REST against the public endpoint, WebSocket for streams. Both are free with no signup.

REST API: Info and Exchange Endpoints

The REST API is Hyperliquid’s foundational interface and splits into two distinct endpoints. POST https://api.hyperliquid.xyz/info handles all reads — account state, market metadata, fill history, vault data, funding rates, leaderboard queries. POST https://api.hyperliquid.xyz/exchange handles all writes — orders, cancels, transfers, vault deposits, validator actions. Every Exchange request requires an ECDSA-signed payload with a nonce for replay protection. Subaccounts and vaults sign through the master account with vaultAddress set on the request.

• ✅ Universal foundation. Every framework, every language, every bot uses REST. SDKs simply wrap the underlying HTTP requests.
• ✅ Free public endpoint. Both Info and Exchange are accessible without signup, ideal for prototyping and one-off scripts.
• ✅ Pagination built in. Time-range queries return up to 500 elements per call; use the last returned timestamp as the next startTime to walk through history.
• ⚠️ 100 req/min cap on the EVM RPC. The Exchange endpoint and Info endpoint sit on the trading API path and have separate volume-based limits — but the public HyperEVM RPC is the bottleneck for any contract-reading bot.
• ⚠️ Pull-based. Polling for live data wastes requests. Use REST for snapshots, then switch to WebSocket or gRPC for ongoing updates.
• ⚠️ 500-element ceiling on time-range queries means historical data collection requires loop logic. Frameworks like Freqtrade handle this incrementally.
• 📌 Best for: Order placement and cancels, account state on bot startup, one-shot metadata queries, and any sequential read that doesn’t need streaming.

Sample Info request (account state):

curl -X POST https://api.hyperliquid.xyz/info \
  -H "Content-Type: application/json" \
  -d '{"type":"clearinghouseState","user":"0xYourAddress"}'

WebSocket API

The WebSocket API is the default mechanism for real-time data on Hyperliquid. Connect to wss://api.hyperliquid.xyz/ws (or wss://api.hyperliquid-testnet.xyz/ws on testnet), then send subscription messages to receive push updates as events occur. Subscription types include trades, l2Book, candle, allMids, userFills, userFundings, liquidations, bbo, webData2, and webData3. Time-series subscriptions deliver a snapshot first (tagged isSnapshot: true) followed by streaming updates. The system has a 1,000-subscription per-IP cap.

• ✅ Push-based delivery. Updates arrive as events occur — no polling overhead, no artificial latency from request intervals.
• ✅ Free public endpoint. Same URL for everyone, no signup required. Private RPC providers offer their own WebSocket endpoints with higher reliability and observability.
• ✅ Comprehensive subscription set. Trades, L2 book, candles, BBO, user fills/fundings, liquidations, plus aggregate webData2 and webData3 for combined market + user state.
• ✅ Snapshot + stream pattern. Reconnection logic gets a fresh state snapshot, then resumes streaming — no manual gap-filling required.
• ⚠️ 1,000 subscription cap per IP. Tracking thousands of markets or wallets requires either multiple WebSocket connections or migration to gRPC.
• ⚠️ Reconnection logic is your responsibility. Disconnections happen periodically. Implement exponential backoff (1s, 2s, 4s, capped at 60s) and handle the snapshot replay on reconnect.
• ⚠️ WebSocket on private RPC providers sometimes only on specific paths — QuickNode requires /nanoreth; Chainstack supports both /evm and /nanoreth.
• 📌 Best for: Live order book tracking, real-time trade feeds, user fill notifications, candle streams for indicators, and any bot that reacts to market events as they happen.

Sample subscription (live trades for SOL):

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

gRPC HyperCore Streaming

gRPC HyperCore streaming is the high-frequency option, available only through paid RPC providers. The pattern is purpose-built for HFT-grade workloads: persistent connections, binary protocol, server-side filtering, and dedicated streams for trades, orders, book updates, TWAP, events, blocks, and writer actions. Performance characteristics commonly cited are 70+ blocks per second processing with sub-second latency. As of early 2026, three providers offer managed gRPC for Hyperliquid: Dwellir (with L2/L4 order book server and co-located VPS), QuickNode (seven unified streams via beta), and HypeRPC (validator-near routing in Tokyo).

• ✅ Sub-second tail latency. Persistent binary connections process events as they hit the network, without WebSocket framing or JSON parsing overhead.
• ✅ Server-side filtering. Subscribe to specific coins, addresses, or event types — bandwidth costs scale with what you actually consume, not the full feed.
• ✅ Seven HyperCore streams. Trades, orders, book updates, TWAP, events, blocks, and writer actions — covers the full event surface that matters for trading bots.
• ✅ L4 order book detail (Dwellir). Individual order visibility with user addresses, order IDs, and timestamps. Five times the depth of the public API (100 levels per side vs 20).
• ⚠️ Provider-only. No public gRPC endpoint exists. Pick from Dwellir ($699/mo), QuickNode (included on paid plans, beta), or HypeRPC.
• ⚠️ Higher integration complexity. Requires gRPC client libraries (e.g. grpcio in Python), .proto schema files, and bidirectional streaming logic. Not a drop-in replacement for WebSocket.
• ⚠️ Lock-in to provider format. Each gRPC provider exposes slightly different message schemas. Switching providers requires reworking the consumer.
• 📌 Best for: HFT bots, market makers, latency arbitrage, real-time analytics dashboards, and any workload where you’ve measured a real WebSocket or polling bottleneck.

Routing Verdict: Building Production Bots Across All Three

Real Hyperliquid bots don’t pick one mechanism — they layer. Here’s how a typical production stack uses all three:

• Bot startup: REST /info for clearinghouse state, asset metadata, current open orders, and account leverage. One-shot reads to initialise local state.
• Live market data: WebSocket subscriptions for the coins your strategy trades — l2Book, trades, and bbo for execution decisions; candle for indicator inputs.
• User events: WebSocket userFills and userFundings for fill confirmations and funding-rate accruals — push notifications eliminate fill polling.
• Order placement: REST /exchange with ECDSA-signed payloads. Always. Batch up to 39 orders per call for weight 1 if you’re rebalancing.
• HFT or market-making: gRPC streams from Dwellir, QuickNode, or HypeRPC for order book updates and trade feeds — sub-second latency advantage over WebSocket.
• Historical data and backtesting: REST /info with pagination — 500 elements per call, 5,000-candle ceiling per coin per call, walk forward via timestamp.

The decision that drives gRPC adoption is honest: have you measured a tail-latency wall on WebSocket? If your p95 fill confirmation time is under 200ms and your strategy works fine, WebSocket is the right call. gRPC adds operational complexity, provider lock-in, and meaningful monthly cost. Reach for it when your strategy genuinely depends on the marginal latency improvement — not because it sounds faster on the marketing page.

Two operational reminders. First: private RPC providers don’t replace the official Exchange endpoint. Order placement and cancels still route through api.hyperliquid.xyz/exchange. Private RPC accelerates reads and streams, not writes. Second: WebSocket subscription cap is real. If you’re tracking 100+ wallets for a copy-trading strategy, plan multiple connections or migrate to gRPC before you hit the 1,000-subscription per-IP ceiling. For a refresher on RPC provider selection, our Hyperliquid RPC providers comparison covers the eight main options across both layers.

Frequently Asked Questions

Can I place Hyperliquid orders over WebSocket?

The WebSocket API supports a Post Request mechanism that wraps Exchange endpoint calls inside the WebSocket connection, but the underlying execution still goes through the official Exchange path. Most bots find it cleaner to use REST /exchange for orders directly and reserve the WebSocket connection for subscriptions. SDKs like the official Python SDK and CCXT default to this split — REST for writes, WebSocket for streams.

When should I switch from WebSocket to gRPC?

Switch when you’ve measured one of three constraints. First: WebSocket’s 1,000-subscription per-IP cap is binding and you’d rather not run multiple connections. Second: your p95 or p99 latency on critical events (book updates, fills) is breaking strategy assumptions. Third: you need L4 individual order detail (user addresses, order IDs) that WebSocket’s L2 book doesn’t provide — Dwellir’s gRPC order book server is the path here. If none of those apply, WebSocket is the right call and saves you the operational complexity.

What’s the Hyperliquid API rate limit for trading bots?

Rate limits are volume-based, not strict per-minute caps. You get 1 request per 1 USDC of cumulative trading volume, plus a 10,000-request initial buffer for new accounts. Batching helps — up to 39 orders in a single Exchange request count as weight 1. The separate 100 requests-per-minute cap that gets quoted is on the public HyperEVM RPC at rpc.hyperliquid.xyz/evm, not the trading API. Trading-side limits scale with volume, so active bots rarely hit them.

Production Hyperliquid bots use REST for writes, WebSocket for live reads, and gRPC only when the marginal latency justifies the cost. The decision tree is simpler than it looks: if you’re placing orders, REST. If you’re tracking the market in real time, WebSocket. If you’ve measured a tail-latency wall, gRPC. Combine that with the right framework and RPC provider and you have the full stack.

Reviewed by Gaurav Agarwal, founder of CoinCodeCap. Gaurav has covered crypto exchanges, DeFi protocols, and trading platforms since 2018. API endpoints, subscription types, and rate limits verified against the official Hyperliquid documentation as of May 2026.

⚡ Bottom Line: Use REST /exchange for all writes (no alternative exists), REST /info for one-shot reads, WebSocket for live market and user feeds (subject to the 1,000-subscription per-IP cap), and gRPC HyperCore streaming only when WebSocket has hit a measurable wall. gRPC requires a paid provider — Dwellir, QuickNode, or HypeRPC. Most production bots use all three mechanisms layered together: REST for snapshots and writes, WebSocket for ongoing reads, and gRPC only for HFT-grade workloads.

📋 Related Guides: Best Hyperliquid RPC Providers | Best Hyperliquid Bot Frameworks | No-Code Hyperliquid Bot Setup
📊 Comparisons: Hyperliquid vs dYdX, GMX & Competitors
⬆️ Full Review: Hyperliquid Review — Is It Safe, Legit & Worth Switching?