Hyperliquid Data & API: HIP-3 Markets, Feeds & Historical Data

If you want programmatic access to Hyperliquid's HIP-3 markets — the builder-deployed perps for equities, commodities and pre-IPO names that sit alongside the core BTC/ETH/SOL book — the good news is there's no separate API to learn. HIP-3 markets are served by the same Hyperliquid info endpoint as everything else; the one new idea is that you have to tell it which perp dex you mean. This post is the developer-facing companion to What Is Hyperliquid HIP-3?, which explains the framework itself; here the question is practical: how do you read these markets, what data is actually available, and what does someone mean when they search for a 'HIP-3 data provider'. It also maps the wider Hyperliquid data landscape a builder-market integration eventually runs into — the live /info REST and WebSocket API, the S3 historical archive, and low-latency node data — and where each fits.

Published June 25, 2026. Last updated July 1, 2026.

One API, many perp dexs

Hyperliquid's core perps live on the default perp dex — an empty-string dex name in the API. Every HIP-3 market a builder deploys is its own named perp dex on the same L1, the same order book infrastructure, and the same info and exchange endpoints. So the architecture you already use for BTC perps is the architecture for a HIP-3 equity perp; the difference is a single parameter that selects the dex.

Start by listing what exists. The info endpoint's perpDexs request returns every perpetual dex on Hyperliquid with its metadata — name, deployer, fee recipient, and the per-asset OI caps and funding multipliers the builder set. That's your discovery call: it tells you which builder markets are live and what each one is called, which you need before you can query any of them by name.

Reading a HIP-3 market's metadata and prices

Two requests carry most of the load, and both accept an optional dex parameter. meta returns the universe for a dex — the asset list with leverage and size-decimal settings, plus the margin tables. metaAndAssetCtxs returns that same metadata bundled with live asset contexts: mark price, current funding, open interest and the rest of the per-asset state. To read a builder market instead of core perps, you send the same request with "dex" set to that builder's name rather than the empty string. That one field is the whole trick.

Two more requests are HIP-3-specific and require a non-empty dex name: perpDexLimits exposes the deployment's configured limits, and perpDexStatus reports the dex's operational state. OHLC candles come from the same candleSnapshot request used for core markets, keyed by the market's coin name. For the exact request bodies, field names and rate limits, read Hyperliquid's official API documentation — it is the source of truth and it changes; this post is the map, not the schema.

Coin naming is namespaced and case-sensitive

A practical gotcha that breaks integrations on day one: HIP-3 coins are namespaced by their dex and the names are case-sensitive. On trade.xyz's dex — the builder that runs most of the equity and pre-IPO markets — Tesla is not 'TSLA' but the fully-qualified, exact-case symbol the dex assigns (think a dex-prefixed form such as 'xyz:TSLA'). A core-perp symbol like 'BTC' will not resolve on a builder dex, and a lowercased or unprefixed equity symbol will silently return nothing. Always resolve coin names from the dex's own meta universe rather than hardcoding tickers, and preserve case exactly as the API returns it.

What data exists — and what doesn't

The live state is rich: mark and oracle prices, funding, open interest, the full order book, and trades are all available per HIP-3 market through the standard endpoints. Where builder markets differ from majors is history and anchoring, and both matter if you're building anything backward-looking. These markets are young — a dex only has price history back to its own launch date, so a market that went live in late 2025 simply has no 2024 candles to backtest against, no matter how you query. Treat 'days since launch' as a hard input, not a detail.

Two more limits worth designing around. First, there is no spot market underneath a synthetic equity or pre-IPO perp, so the price is anchored by the builder's oracle methodology rather than by arbitrage against a deep spot book — the data is only ever as good as that oracle. Second, deep historical open-interest series are not something to assume; you can read current OI from the asset context, but reconstructing a long OI time series usually means polling and storing it yourself. If your model needs historical OI on a builder market, budget to collect it going forward rather than expecting to backfill it.

Beyond the info API: feeds, history, and low latency

The info endpoint is the right tool for reading HIP-3 markets, but it's one of several ways to get Hyperliquid data, and search terms like 'Hyperliquid data feed', 'S3 data', 'fills API' and 'low latency data' each map to a different tier: the live REST and WebSocket API for real-time reads, the S3 archive (hyperliquid-archive and hl-mainnet-node-data, LZ4, requester-pays, roughly monthly) for deep history, and a self-run non-validating node for the lowest latency. Picking the right tier saves a lot of wasted engineering.

That's a separate topic from HIP-3 itself, so it has its own guide — see Hyperliquid Market Data & API for the full breakdown of feeds, historical S3 access, fills data and low-latency node setup. The rest of this post stays on the HIP-3-specific question: how builder markets differ once you're reading them.

What 'HIP-3 data provider' usually means

The phrase gets searched two different ways, and they want opposite things. One is a builder evaluating whether to deploy and operate a HIP-3 market — for that, the bond, oracle and fee mechanics in What Is Hyperliquid HIP-3? and the fee distinction in Hyperliquid Builder Codes Explained are the relevant reading. The other, and the more common one, is a developer or desk that wants a clean, normalized feed of HIP-3 market data — prices, funding, OI across the builder markets — without each integrating the raw info endpoint and maintaining their own history.

The honest answer for the second group is that Hyperliquid is itself the canonical source — the info endpoint above is the provider, and it's free and permissionless. A third-party 'data provider' on top of it is really offering normalization, history retention and uptime: storing the candles and OI that the chain doesn't keep for you, mapping the namespaced coin names to something stable, and serving it with an SLA. That's a real service, but be clear about what you're paying for — convenience and history over the live data, not access to data that's otherwise locked away.

Where Signalview fits

Signalview (our product) is a consumer of this data, not a reseller of it. Our agents read HIP-3 markets through exactly the path described here — the dex-scoped info endpoint, with coin names resolved from each dex's own universe — to drive non-custodial AI agents that trade a backtested score on Hyperliquid, including the TradFi perps on the xyz dex. We mention it only to be straight about our vantage point: we built and run the HIP-3 ingestion this post describes, which is why we can tell you where it's solid (live prices, funding, OI) and where it bites (short history, oracle-anchored marks, no free historical OI).

If you're building your own integration, the framework explainer and builder-codes posts cover the economics, and Hyperliquid's API docs cover the schema. The signal engine we use to backtest strategies on this data is open source — perpsignal, Apache-2.0, at github.com/mokshyaprotocol/signalview — so you can write a signal in its DSL, backtest it, and even contribute new indicators without touching any of the custody or trading code. If what you actually want is a backtested strategy executed on these markets without building the data layer at all, that's the thing our agents do — see What Are AI Trading Agents? for how that works.

Risk note: HIP-3 builder-deployed markets are leveraged, high-risk instruments anchored by builder oracles rather than a spot market, with limited history. Data access does not reduce market risk — you can lose your entire margin. Nothing here is investment advice, and API details should always be confirmed against Hyperliquid's official documentation.

Or skip the build: trade these markets with an agent

If your goal is to trade HIP-3 markets rather than operate the data pipeline, you can browse scored Hyperliquid signals and deploy an AI trading agent that runs a backtested score on these markets 24/7 — non-custodial, with a scoped key that can only place perp orders. Once you've backtested an edge you can also publish your own strategy as a signal and earn when others trade it. Free to run; you pay only Hyperliquid's normal fees, and your funds never leave your wallet.