WebSocket vs REST for Hyperliquid Trading Bots: Which to Use and Why

The first thing most builders do after wiring up a Hyperliquid bot is reach for a WebSocket. It feels right. Trading is fast, WebSockets are fast, therefore the bot needs a WebSocket. Two weeks later they are debugging a reconnect storm at 3am, the bot has missed three signals because the socket dropped and nobody noticed, and the whole thing would have been a cron job hitting REST every fifteen minutes.

This is the transport decision most teams get wrong. REST polling is the right choice for the majority of bots running on our data. Webhooks cover the next slice cleanly. WebSocket only earns its place when you are tracking many assets at once with persistent state. This guide walks through how to make that call for your bot, and which HyperTracker tier maps to each path.

The short version: our analytics refresh every five minutes. WebSocket and Webhooks change how the data reaches you, not how fresh it is. Pick the transport that matches your reaction window and your fan-out, and you are done.

The transport decision most builders get wrong

Transport selection looks like a latency question, but it is actually a connection-cost and architecture question. WebSocket is not a faster version of REST. It is a different shape of pipe, with different operational properties. Once you separate "how fast is the data" from "how does the data reach me," the decision gets a lot easier.

On Hyperliquid itself, the exchange offers WebSocket feeds for raw fills, orderbook updates, and funding events. Those feeds genuinely are sub-second, because they are fired by an L1 that settles in real time. That is one set of decisions and one set of tradeoffs. HyperTracker is a different layer. We classify wallets into cohorts, compute order flow, score liquidation risk, and serve all of that as pre-computed intelligence on a five-minute refresh cycle. Our WebSocket pushes those updates as they happen, instead of you polling for them.

Both are useful. They are not the same thing. The bot you are about to build probably wants one or the other or both, and the difference between getting it right and getting it wrong is whether you ship in a week or spend a month debugging plumbing.

What "real-time" actually means on Hyperliquid

"Real-time" is the most overloaded word in crypto infrastructure, so let's be specific. There are three different cadences in play when a Hyperliquid bot runs against our data, and conflating them is the root of most architectural mistakes.

The chain itself settles in seconds. Every fill, margin update, and liquidation is finalized on Hyperliquid L1 with sub-second finality. If your bot needs to react to a fill the instant it happens (a copy-trade mirror, a dynamic hedger, a liquidation hunter), you are subscribing to the exchange feed, and our analytics layer is not on the critical path.

Funding settles every hour. That is a hard exchange rule, not an API choice. Any strategy that depends on funding flips, funding extremes, or carry economics is operating on an hourly clock no matter what transport you use.

Our cohort and order-flow intelligence refreshes every five minutes. That is the cadence at which we re-classify wallets, recompute segment-level positioning, and refresh smart-money aggregates. Whether you read it via REST, Webhooks, or WebSocket, the underlying data updates on the same cycle. WebSocket does not push faster than that. It pushes as soon as the next refresh lands, instead of you polling for it.

The mental model worth internalizing: pick the cadence that matches your edge, then pick the transport that delivers it cheaply. A signal that depends on a five-minute cohort flip does not get more accurate because you wrapped it in a WebSocket.

REST polling: when it's the right answer

For most bots querying our data, REST polling is genuinely the right answer. It is the simplest possible architecture, it has the best operational properties, and it is the one builders dismiss too quickly because it sounds unglamorous.

The case for REST is straightforward. Each call is stateless. No socket to keep alive, no subscription state to recover after a crash, no message ordering to reason about. You write a function that hits an endpoint, parse the response, and act. If your worker dies, the next cron tick restarts cleanly.

Run the math on a typical setup. A swing bot polling our cohort positioning, funding indicators, and liquidation risk every fifteen minutes across one or two assets is firing roughly two hundred requests a day. That fits inside Pulse ($179/mo, 50K requests/month) with massive headroom for retries and growth. You do not need Stream. You do not need WebSocket. You need a Cloudflare Worker, a cron trigger, and twenty lines of fetch logic.

REST starts to break down on two axes. The first is fan-out: if you are tracking fifty assets and want a fresh read every minute, you are at three thousand requests an hour, and a polling architecture starts looking expensive. The second is reaction window: if your edge depends on responding the moment a cohort flips, polling at fifteen-minute intervals means you might be waiting fourteen minutes and fifty-nine seconds longer than necessary. Either of those constraints points you elsewhere. Below them, REST wins on simplicity.

Webhooks: the middle ground

Webhooks sit between REST and WebSocket and resolve the second of those two problems cleanly. Instead of polling, you give us an endpoint. When a configured event fires (a cohort flip, a liquidation risk threshold, a funding extreme), we POST a JSON payload to your URL and your handler runs.

The shape of a Webhook bot is simple. You expose an HTTPS endpoint behind a small worker. We POST when the event fires. Your handler validates the signature, checks idempotency (more on that in the gotchas section), pulls any extra context via REST, and triggers the trade or the alert. No persistent connection. No polling cost. No "did I miss anything?" reconciliation logic, because the webhook is the trigger.

Webhooks are the right transport when your bot is event-driven on a small number of triggers. A bot that wants to react when Whale-cohort net long on BTC crosses a threshold is one webhook. A bot that wants to fire when liquidation risk on ETH passes 70% is another. You configure the trigger once, and the rest of the time your worker is asleep.

Two things to know. Our webhooks fire on the same five-minute cycle that our REST endpoints serve. They are a delivery mechanism, not a faster pipe to the underlying state. And webhooks are a Flow-tier feature ($799/mo). Pulse and Surge are REST-only. If you can build your bot with a fifteen-minute polling loop and a Pulse plan, do that. If you want event-driven reactivity, the upgrade to Flow buys you both Webhooks and four times the REST budget.

WebSocket: when you actually need it

WebSocket earns its place when fan-out and event volume make REST impractical, and when Webhooks would pile up faster than your handler can process them. There is a real category of bots that fits that description, and if you are building one, the choice is straightforward.

The canonical case is a multi-asset market-making or aggregation bot. You are tracking fifty coins. You want every cohort metric, every order flow snapshot, every liquidation risk update on every coin, the moment our backend recomputes them. Polling fifty endpoints every five minutes pays connection overhead on every single request. Webhooks for that many event types would be a flood of HTTP calls against your handler. A single WebSocket subscribed to the channels you care about delivers all of it down one pipe.

The second case is anywhere you maintain meaningful in-memory state across updates. A bot that keeps a rolling window of cohort positioning, recomputes exposure on every refresh, and triggers off cross-asset signals benefits from a WebSocket because the message stream is the source of truth for the state machine. You receive an update, mutate state, evaluate, repeat. There is no "now go fetch the rest" round trip in the hot path.

Both of those cases want Stream tier ($1,999/mo). That is the only tier with WebSocket access, and it also includes the largest REST budget (2M requests/month) plus Webhooks for the events you do not want flowing through the socket. If you are a single-asset bot firing a handful of trades a day, this is overkill and you should stop reading. If you are a multi-asset shop with persistent state, this is the only transport that fits, and the price is small relative to what you would spend running orderbook and analytics infra in-house.

Three bot archetypes and the right transport for each

The cleanest way to make this decision concrete is to walk through three bots that builders actually ship on our data, and show the transport that fits each.

Archetype A: slow-edge swing bot

Single asset, BTC perp. The bot reads cohort positioning, funding indicators, and liquidation risk every fifteen minutes. When Whale-cohort net long crosses a threshold and funding sits below a level, it opens a long and holds for one to three days. Maybe two trades a week.

The right transport is REST polling. The reaction window is three times longer than our refresh cadence, so you have plenty of headroom. A cron trigger firing every fifteen minutes is roughly three thousand requests a month, comfortably inside Pulse. The bot is stateless between ticks, which means a worker crash recovers on the next cron. Adding WebSocket here piles on operational complexity for zero edge.

Tier: Pulse, $179/mo. Total infrastructure: a cron job and a fetch call.

Archetype B: intra-day mean-revert bot

Single asset, ETH perp. The bot wants to fire the moment a specific cohort metric flips (Money Printer cohort going net short on ETH) and combine that with a fill from the exchange WebSocket. Hold time is hours. The timing of the cohort flip materially affects entry quality.

The right transport here is Webhooks. The bot is event-driven on a small number of triggers, and you do not want to poll an endpoint every minute waiting for a flip that fires once a day. Configure a webhook on the cohort flip, your handler wakes on the event, pulls funding state and order flow context via REST, then submits the trade.

Tier: Flow, $799/mo. You get Webhooks plus a 400K REST budget for the context queries and any backfills. Stream is overkill at this fan-out.

Archetype C: multi-asset market-making bot

Fifty coins. The bot maintains in-memory state for every cohort and order flow metric on every coin. It quotes inventory based on cohort net positioning across the basket, and adjusts spreads when liquidation risk on any coin crosses a threshold. State recomputes on every refresh.

The right transport is WebSocket. Polling fifty endpoints every five minutes pays connection overhead on every call, and the bot needs everything pushed as soon as it lands. A WebSocket subscribed to the cohort and order-flow channels for those fifty coins delivers all of it down one connection. The bot mutates state on each message. REST is reserved for backfills and ad-hoc queries.

Tier: Stream, $1,999/mo. WebSocket plus the 2M REST budget for everything that does not flow through the socket.

Operational gotchas

Whichever transport you pick, the production failure modes are predictable. Here are the three that bite builders most often.

Reconnect logic on WebSocket

WebSocket connections drop. Networks fail, intermediate proxies recycle, our backend deploys. Production-grade WebSocket clients use exponential backoff with jitter, cap the retry interval at something sane (30 to 60 seconds), and resubscribe to all channels on reconnect. The naive "while true: try connect" loop is a foot-gun: when our backend hiccups, every client on the planet retries simultaneously and creates a thundering herd.

The pattern that works: detect the disconnect, wait min(base * 2^attempt + random(), max), reconnect, resubscribe, then on the first message after reconnect, reconcile state by pulling the current snapshot via REST. Treat the WebSocket as a delta channel layered on top of a REST snapshot, never as the sole source of truth.

Missed messages and idempotency on Webhooks

Webhooks are at-least-once delivery. We retry on non-2xx responses, which means your handler may see the same event twice. Make every webhook handler idempotent. Use the event ID we send as a deduplication key, store it in Redis or a small SQL table, and skip the trade if you have already processed that ID.

The other failure mode is the inverse: your webhook endpoint is down for two minutes, we retry for a while and eventually give up. On startup, your handler should reconcile by pulling the recent event log via REST and comparing against what it has already processed. Webhooks are the trigger, REST is the audit log.

Partial fills and trade pairing

If your bot tracks closed trades on the wallets it copies or follows, the closed-trades surface handles partial fills and round-trip pairing for you. Do not try to compute trade-level metrics from raw fills or position snapshots. Position snapshots fire at unpredictable intervals and are not a closed-trade ledger; raw fills require pairing logic that breaks the first time a wallet flips long-short-long inside a minute. The closed-trades summary endpoint returns wins, losses, total trades, and average duration directly, and it works the same way over REST, Webhooks (via Flow tier triggers), or WebSocket (Stream tier subscriptions). Use it.

Picking your tier with the architecture in mind

The clean way to read our pricing is to start with the transport your bot needs and work backward to the tier.

| Tier | Price | Transport | Best fit | | --- | --- | --- | --- | | Free | $0 | REST, 100/day | Prototyping, exploration | | Pulse | $179/mo | REST, 50K/mo | Single-asset swing bots, dashboards | | Surge | $399/mo | REST, 150K/mo | Higher-volume polling, internal tools | | Flow | $799/mo | REST + Webhooks | Event-driven reactive bots | | Stream | $1,999/mo | REST + Webhooks + WebSocket | Multi-asset, persistent state, market-making |

Two practical rules of thumb. If you can describe your bot as "every fifteen minutes, do X," you want Pulse. If you can describe it as "when X happens, do Y," you want Flow. If you cannot describe it without listing fifty assets and a state machine, you want Stream.

Build on our data

Pulse ($179/mo) covers most single-asset bots. Flow ($799/mo) adds Webhooks for event-driven reactivity. Stream ($1,999/mo) adds WebSocket for multi-asset persistent-state bots. Free tier available for testing (100 requests per day, no credit card).

View pricing →

Closing the loop

Transport choice is a question of architecture, not bragging rights. WebSocket is not a faster version of REST any more than a fire hose is a faster version of a faucet. They are different tools, sized for different jobs. Pick the one that matches your reaction window and your fan-out. Build the simplest thing that handles your case. Ship the bot. Ignore the next person on Twitter who says you need WebSocket because it is "faster." Our data refreshes every five minutes either way. The fastest bot is the one that is actually running.