Live stream (WebSocket)

One endpoint: a credential-gated WebSocket that pushes closed OHLCV bars for the subscriptions you hold. Those bars are Hyperliquid's, read from HL's own fill stream, and they are the only series this endpoint carries. It runs in the vike.io application, not the one that serves every /v1 namespace on data.vike.io.

Endpoint

wss://vike.io/v1/stream

WEBSOCKET wss://vike.io/v1/stream

Subscribe to one or more Hyperliquid series and receive a bar frame each time a candle closes. Use it when you want to be told a bar has completed without polling GET https://data.vike.io/v1/hyperliquid/ohlcv on a timer; use REST for history, for warm-up, and for backfilling a gap.

The handshake takes one optional query parameter. Everything else is negotiated over the socket after it opens.

The edge allows the WebSocket upgrade and drops a connection that goes 300 seconds without data. The server's ~15-second heartbeat keeps traffic well inside that window.

What it streams: Hyperliquid, from our own node

The feed is driven by the same engine behind /v1/hyperliquid/ohlcv, reading one-minute and one-hour rollups built from Hyperliquid fills captured by a node Vike runs itself. That is the whole source: one venue, our own node, and the same series the REST endpoint serves. The one-minute rollup trails wall clock by 18 seconds, measured 2026-09-03, which is the lag the 15-second poll cadence is sized for.

Which markets and DEXs are reachable

An HL bar is not identified by symbol alone, so the subscription carries two more fields:

Symbols follow the REST endpoint: a perp ticker (BTC), a spot token (HYPE) or a raw spot index (@107). Whatever you send is stripped and upper-cased before use.

What changed for a client, and what did not

The wire protocol is unchanged: subscribe/unsubscribe/pong, the bar frame shape, the monotonic seq, the closed flag, the ~15-second ping, the bounded outbound queue and the seq-gap-then-backfill recovery path are all exactly as they were. A client written against the published spec still connects, still subscribes with {symbol, interval}, and still parses every frame. Since 2026-09-03 the data behind those frames is Hyperliquid's, so a client written before that date sees three differences:

• Symbols are HL assets (see the callout above). The venue is pinned by construction — it is Hyperliquid — and market/dex select within it.
• Six intervals are gone. 3m, 2h, 6h, 8h, 12h and 1w are not in HL's set. A subscription to one is now an error frame, not silence.
• funding is still always null, for a new reason: HL candle rows carry volume_usd and n_trades, never a funding rate.

Authenticating the handshake

The handshake tries three credential sources in this order and stops at the first that produces an identity:

Both header forms reach the same account — the same rule as the REST surface, see Authentication.

What a refusal looks like

If no source yields an identity the connection is closed with code 4401, and it is closed before the handshake completes. Most clients surface that as an HTTP 403 on the upgrade rather than as close code 4401.

Subscribing

After the socket opens, send JSON text frames. Exactly three values of action are accepted:

{"action": "subscribe",   "channel": "bars", "symbol": "BTC",  "interval": "1m"}
{"action": "subscribe",   "channel": "bars", "symbol": "HYPE", "interval": "5m", "market": "spot"}
{"action": "subscribe",   "channel": "bars", "symbol": "BTC",  "interval": "1m", "dex": "XYZ"}
{"action": "unsubscribe", "channel": "bars", "symbol": "BTC",  "interval": "1m"}
{"action": "pong"}

Intervals are the HL engine's time intervals:

1m  5m  15m  30m  1h  4h  1d

The subscription key

A subscription is (symbol, interval, market, dex) — all four fields, and everything the server does with a subscription (registering it, attaching, detaching, tearing it down) keys on all four. Consequences:

• BTC/1m perp and BTC/1m spot are two independent subscriptions with two independent feeds and two independent seq counters. They never collide, and neither do two builder DEXs.
• Unsubscribe with the same four fields you subscribed with. The key is re-derived from the unsubscribe message, so unsubscribing {symbol, interval} does not cancel a spot subscription — the keys differ, and the call is a silent no-op.
• Subscribing to a key you already hold on that connection is a no-op; so is unsubscribing from one you do not hold.

The error frame

Every client-side rejection uses the same shape and, today, the same code:

{"type": "error", "code": "bad_subscription", "message": "unknown action 'frobnicate'"}

message is the only field that varies, and it now diagnoses rather than gestures — each fault has its own message, checked in this order:

Malformed JSON, a non-object payload and an unknown action are caught earlier still, before the subscription is built, and arrive with the same code. The socket stays open in every case; a rejected message is discarded and the connection continues.

Server frames

Two frame types reach the client in normal operation — bar and ping — plus the error frame above.

bar

The frame shape is fixed, and a test holds it that way:

The shape — the numbers are illustrative, and BTCUSDT here is a placeholder the server never inspects, not a symbol that would return bars from HL:

{
  "type": "bar", "symbol": "BTCUSDT", "interval": "1m",
  "ts": 1738411260000, "open": 1.0, "high": 2.0, "low": 0.5,
  "close": 1.5, "volume": 10.0, "funding": null, "closed": true, "seq": 5
}

ping

{"type": "ping"}

Heartbeat

The server sends {"type": "ping"} every 15 seconds. The client must answer with a pong message, which resets the miss counter to zero.

The counter is incremented immediately before each ping is sent, and the connection is closed with code 1011 once it exceeds 3 missed pongs. A client that never ponged is therefore dropped on the fourth heartbeat tick, roughly 60 seconds after the socket opened.

Note also that the server reads text frames only. Binary messages are not part of this protocol.

Sequence numbers and gaps

seq is what tells you a frame went missing, and its scope is the part that surprises people: it belongs to the (symbol, interval, market, dex) feed, not to your connection.

There is one shared feed per active key on the server, with one poller serving every subscriber. Its counter starts at 0 when the feed is created — that is, when the first client anywhere subscribes to that key — and the feed is torn down when its last subscriber leaves.

The consequences worth planning for:

• If you subscribe to a key somebody else is already watching, your first frame's seq is not 1. It is wherever that feed had got to.
• If you are the only subscriber and you unsubscribe and resubscribe, the feed is destroyed and rebuilt, and seq restarts at 0. A seq you saw before is not comparable with a seq you see after.
• seq does not survive a server restart, and it is per-process.

Use seq for what it is designed for — detecting a gap within one continuous subscription — and not as a durable cursor.

Backpressure

Each connection has a bounded outbound queue of 1000 frames. When a slow consumer's queue is full the server counts the drop and moves on: the feed never blocks on one slow client. You observe the loss as a jump in seq, and the documented recovery is to backfill the missing window over REST — GET https://data.vike.io/v1/hyperliquid/ohlcv with the same symbol, interval, market and dex, over the ts range you missed (Hyperliquid OHLCV). That is the same series the feed polls, so the backfilled bars are the same bars.

What closes the connection

On every one of these, all of that connection's subscriptions are detached, which tears down any feed left with no subscribers.

Freshness, and what the bars actually are

Each feed polls the HL series once every 15 seconds and broadcasts whatever closed bars are new since its last poll. The one-minute rollup behind it trails wall clock by 18 seconds, measured 2026-09-03.

These are closed bars only. There is no live forming candle, and the 18 seconds is not delivery latency at the bucket boundary — it is how long after the boundary the bar becomes readable at all. Stack the poll cadence on top and a closed bar reaches you somewhere in the region of 18 to 33 seconds after it closed, depending on where the boundary falls between two polls. That range is arithmetic over two constants, not an end-to-end measurement; nobody has timed a frame on the wire (see Known gaps).

Two mechanics behind that, both visible from outside:

• The poller floors its own window. It asks only for buckets that have already closed, explicitly ending the window at the open of the forming bucket — otherwise it would ship a partial bar stamped closed: true that nothing would ever correct. So a subscription never emits the bar that was forming when you subscribed until it closes, and never emits a partial bar at all.
• A fresh subscription is quiet until the next boundary. A new feed starts just before the forming bucket's open, so its closed window is empty and it queries nothing until a bucket closes. On 1m bars at 15-second polls that is up to three silent cycles; on 1d it is up to a day. Warm-up history comes from REST, not from the stream.

Load, and what a connection costs

Fan-out is per subscription key, not per connection: 1,000 clients watching BTC/1m on the core perp produce one engine query per 15-second cycle, delivered 1,000 ways. Cost scales with the number of distinct keys subscribed across the whole process, not with the number of connections.

On metering: today this endpoint runs no rate-limit check and writes no usage record — authenticating the handshake is the entire gate, and there is no second gate at the edge. That is current behaviour, not a published allowance, so do not design around a stream being free. The hourly budget and its documented home are on Rate limits.

Why you cannot probe it

This endpoint cannot be confirmed or refuted by curling it, which is a large part of why it went undocumented for so long:

• The server answers 403 identically for an unmatched WebSocket path and for a connection refused before the handshake completes. /v1/stream and /v1/nope are indistinguishable from outside.
• The edge behaves differently by protocol. Over HTTP/2, Connection: Upgrade is rejected outright — measured as a 400. Over --http1.1 the request reaches the application and returns 403. A probe run over h2 will look like proof the endpoint does not exist.

The only positive confirmation is a completed connection: open the socket over HTTP/1.1 with a valid credential, subscribe to a symbol you know trades on HL, and wait for a bar.

Known gaps in this page

• No observed traffic. No bar on this page was captured from the live endpoint, and the 18-to-33-second delivery window above is arithmetic over the measured data lag and the poll cadence, not a timing anyone has taken on the wire.
• Multi-worker behaviour is not specified. A feed is per-process, and single-process operation is what is assumed today. What seq would do across several processes is not settled, so this page does not claim it.