How to Get Hyperliquid Historical Data: S3 Buckets, the Info API, Your Own Node or a Raw Archive

Ask Hyperliquid's public info API for 1-minute BTC candles from January 2023 and you get 5,055 bars that start on 8 November 2026. Ask for daily candles and you get bars back to August 2020, two and a half years before the first bar with any trades in it. Both answers come back with HTTP 200 and no warning.

Hyperliquid historical data comes from four places: Hyperliquid's S3 buckets, the info API, a node you run, and archives kept by someone who started recording before you did. Each one stops somewhere different. This guide shows where, with every limit tested or quoted from a primary source and dated. We ran the API calls on 11 November 2026.

The four sources at a glance

If you only need bars for a chart or a quick test, the info API is enough. Anything older, finer or order-level needs one of the other three.

Hyperliquid's S3 buckets

Hyperliquid publishes raw history to two Amazon S3 buckets, documented on its historical data page. Both are requester pays. An anonymous request is refused with Anonymous users cannot invoke requests against Requester Pays buckets, so you need an AWS account with billing enabled, and every download is charged to you.

The regions come from the x-amz-bucket-region header S3 returns for each bucket. They matter for cost: AWS charges $0.09 per GB to the internet from us-east-1 and $0.114 per GB from Tokyo for the first 10 TB a month, after a 100 GB monthly free allowance (AWS price list, published 10 November 2026). Pulling into an EC2 instance in the same region avoids the internet transfer charge.

These are Hyperliquid's own example commands, with a listing step added:

# List what is there (charged to your account)
aws s3 ls s3://hl-mainnet-node-data/ --request-payer requester

# One hour of SOL L2 snapshots from the docs example
aws s3 cp s3://hyperliquid-archive/market_data/20230916/9/l2Book/SOL.lz4 /tmp/SOL.lz4 \
  --request-payer requester
unlz4 --rm /tmp/SOL.lz4
head /tmp/SOL

Four things decide whether S3 works for your job.

Uploads are slow and not guaranteed. For hyperliquid-archive, the docs say data is uploaded "approximately once a month" and "there is no guarantee of timely updates and data may be missing." They state no cadence for hl-mainnet-node-data. If you need last week, list the bucket first and check that it is there.

hyperliquid-archive has no candles and no spot asset data. The docs state it directly: "No other historical data sets are provided via S3 (e.g. candles or spot asset data)." You build bars from fills yourself.

Fills come in three formats. node_trades is the oldest and does not match the API format. node_fills matches the API fills format. node_fills_by_block is the current one, written by a node running --write-fills --batch-by-block, with one block per line. A downloader that parses one prefix silently returns nothing for the others.

Order statuses, book diffs and state snapshots are not there. Hyperliquid's docs list none of them in either bucket. replica_cmds holds the raw signed orders and cancels, but not their applied results, and the market_data files are aggregated L2 levels. Queue position and per-order book history cannot be rebuilt from these files alone.

Requester pays also bills you for each GET and LIST request. To estimate transfer cost before you pull, use a known volume. In Dwellir's archive, which stores the same node_fills_by_block node output, one month averages about 26 GB compressed. At $0.114 per GB out of Tokyo that is about $3 a month of fills, or nothing if it fits inside your 100 GB free allowance.

The public info API

The info API at https://api.hyperliquid.xyz/info is free and needs no key. It answers POST requests for candles, funding, your own account and current market state. Its history is short and uneven.

Candles: 5,000 bars per interval

Hyperliquid's info endpoint docs say "Only the most recent 5000 candles are available." We asked for BTC candles from 1 January 2023 at each interval on 11 November 2026 at 12:41 UTC:

curl -s https://api.hyperliquid.xyz/info \
  -H 'Content-Type: application/json' \
  -d '{"type":"candleSnapshot","req":{"coin":"BTC","interval":"1m","startTime":1672531200000}}' \
  | jq '{n: length, first: (.[0].t/1000 | todate)}'

Three more results from the same test matter if you build on this endpoint:

• A window that sits entirely outside the cap returns [] with HTTP 200. Asking for 1-minute candles from 14 to 10 days ago gave zero rows and no error, so a backfill loop sees "no data" rather than "too old."
• Daily BTC candles start on 19 August 2020. Every bar until 26 February 2023 has "v":"0.0" and "n":0. Filter on volume or trade count before treating early bars as Hyperliquid trading.
• There is no 1s interval. Supported intervals run from 1m to 1M, and "interval":"1s" returns HTTP 422.

HIP-3 markets use the dex prefix (xyz:XYZ100, history from 2025-10-13 in our test) and spot pairs use the @index name (@107 daily bars from 2024-11-29).

Funding: complete, but 500 rows at a time

fundingHistory is not capped by count. Responses hold at most 500 rows, so you page forward from the last timestamp. This script pulls the full history for one coin:

import json, time, urllib.request

def info(body):
    req = urllib.request.Request(
        "https://api.hyperliquid.xyz/info",
        data=json.dumps(body).encode(),
        headers={"Content-Type": "application/json"},
    )
    with urllib.request.urlopen(req, timeout=30) as r:
        return json.load(r)

rows, start = [], 0
while True:
    page = info({"type": "fundingHistory", "coin": "BTC", "startTime": start})
    rows += page
    if len(page) < 500:
        break
    start = page[-1]["time"] + 1
    time.sleep(2.5)  # each call weighs about 45; this stays under 1,200 per minute

print(len(rows), rows[0]["time"], rows[-1]["time"])

On 11 November 2026 it returned 30,139 BTC funding rows in 61 calls, from 12 May 2023 to the current hour. Funding was every 8 hours until 8 June 2023 and hourly after that. Three single hours are missing: 2023-07-02 20:00, 2023-08-23 20:00 and 2024-08-15 13:00 UTC. Check for gaps before you sum funding over a period.

Account history: capped by count

Fills older than the latest 10,000 are not available from the API at all.

What has no history at all

Some data the API only serves as of now:

Rate limits

REST requests share 1,200 weight per minute per IP (rate limits). Most info requests weigh 20, l2Book weighs 2, candleSnapshot adds weight per 60 candles returned, and fundingHistory and the fill requests add weight per 20 rows. A full 5,000-candle response weighs a little over 100, so you can pull about 11 of them a minute from one IP.

Running your own node

A non-validating node sees every block and can write most of what the chain does to disk. The node README (last changed 10 August 2026) lists the minimum:

What the node records depends on its flags:

~/hl-visor run-non-validator --write-fills --write-order-statuses \
  --write-raw-book-diffs --write-misc-events --batch-by-block \
  --replica-cmds-style actions-and-responses

The node also writes a full state snapshot (periodic_abci_states) every 10,000 blocks, about every 12 minutes at current block rates.

A node has two limits as a history source.

It has no past. It writes from the first block it applies. The README says the local info server handles "a subset of requests that are entirely a function of local state. In particular, historical time series queries and websockets are not currently supported." A node started today gives you today onward.

The disk fills fast. The README puts default output at about 100 GB of logs a day. With every output on, the volume is far higher. Dwellir's archive of the same outputs, compressed with LZ4, averages 4.99 TB a month for replica_cmds with responses, 2.90 TB for ABCI states, 2.19 TB for order statuses and 459 GB for book diffs. That is about 350 GB a day compressed, so a 500 GB minimum disk holds less than two days unless you ship files off the machine as they close.

Old state snapshots can also become hard to read. Hyperliquid publishes only the latest node binary, and the snapshot format changes with some upgrades. In Dwellir's tests on 12 October 2026, the node binary built on 10 October 2026 could not export snapshots from 1 to 12 September 2026 (missing field ktm), and an August build failed on the 1 September snapshot with a different missing field. Keep a dated copy of each binary, or decode the MessagePack directly; Dwellir's abci_to_l4.py example rebuilds L4 books from older snapshots without the node.

A node also needs reliable peers to stay in sync. If you run one, see how to peer a non-validating Hyperliquid node.

What Dwellir's raw node archive adds

Dwellir runs Hyperliquid nodes with these outputs on and keeps the files in their source format. The archive starts earlier than any node you could start now, and it holds the order-level feeds that Hyperliquid's buckets leave out. Start dates match the historical data page and a listing of the bucket on 11 November 2026; sizes are monthly averages from the coverage table.

The fill prefixes overlap at their edges, so pick the parser from the prefix and the record shape. Hyperliquid archival data covers the fill generations and parser traps in detail. The data catalog has a page per prefix with real sample records and every observed field.

Since 3 November 2026, each hourly file has reached the bucket shortly after its hour closes. In the 11 November listing, fills for each hour landed about 2 minutes after the hour, and order statuses about 20 minutes after. Customers get a read-only S3 key limited to the prefixes and dates they bought, and any S3 client works with it.

For jobs that do not need raw files, two processed products sit on top of the archive. The Hyperliquid Index serves 1s, 1m and 5m candles for perps, spot pairs and HIP-3 markets, with history from 2025-07-27. Indexed fills answer wallet, builder and market queries and page with a cursor back to 2025-07-27. Both are included in Dwellir API plans from $49/month. Candle ranges bill 1 API credit per candle returned, and fills 1 credit per fill. This call returned BTC 1-minute candles from 2025-07-27 08:50 UTC, about 15 months further back than the public API:

curl "https://api-hyperliquid-index.n.dwellir.com/YOUR_API_KEY/v1/candles/range?market=BTC&interval=1m&start=2025-07-27T00:00:00Z&end=2025-07-28T00:00:00Z&limit=5000"

Tick data turns node_fills_by_block into flat CSV or Parquet, one row per fill.

What Dwellir does not offer

Funding rate and open interest history are not a listed Dwellir product. For funding rates, the free fundingHistory request above goes back to May 2023. misc_events_by_block records each account's funding payment with its rate and position size from 29 June 2026, but those are raw events, not a ready series. For open interest history, Hyperliquid's asset_ctxs files are the source with no data fee.

Dwellir has no order book history before 2026. Its order-level history starts on 2026-01-22, and stored seeds for rebuilding a book start on 2026-04-14. Hyperliquid's market_data files go back much further at L2.

The raw archive is files, not a query API. You download whole hourly or 10,000-block objects that cover every market, then filter. A filtered or decoded export for a few markets is custom work, quoted separately. No archive is gap-free, Dwellir's included: ask for the gap and repair list for your window before you buy.

Data providers

If you would rather query history than parse files, several providers record Hyperliquid and serve it through their own APIs or file buckets. Three examples:

• 0xArchive serves books, trades, funding and open interest over REST, WebSocket replay and Parquet exports. Its 7 October 2026 guide lists L2 books from April 2023, funding and open interest from May 2023 and L4 from March 2026. For a query API over funding and open interest, it covers what Dwellir does not.
• Tardis.dev records the public WebSocket feed from 2024-10-29, so its books are the snapshots Hyperliquid publishes: 20 levels about every 5.4 seconds, plus a 5-level feed about every 500 ms from 2026-06-17.
• Hydromancer Reservoir is a free requester-pays S3 bucket of Parquet fills, 1-second candles and 1-minute L2 snapshots, with fills from 28 July 2025.

Providers differ on start dates, billing units and whether their books are L2 snapshots or full order-level data. Hyperliquid backtesting data: 20 sources compared puts them side by side on coverage, format and cost.

Which source for which job

Frequently asked questions

Is Hyperliquid historical data free?

Partly. The public info API is free and needs no key, but it keeps only the most recent 5,000 candles per market and interval and has no history for open interest, order books or market-wide trades. Hyperliquid's S3 buckets have no data fee, but they are requester pays, so you need an AWS account and you pay AWS transfer: $0.114 per GB out of Tokyo for hl-mainnet-node-data and $0.09 per GB out of us-east-1 for hyperliquid-archive, after AWS's 100 GB monthly free allowance (AWS price list, 10 November 2026).

How far back do Hyperliquid API candles go?

The info API returns about the most recent 5,000 candles for each market and interval. Tested on 11 November 2026, 1-minute BTC candles reached back to 8 November, 15-minute to 20 September, 1-hour to 17 April 2026 and 4-hour to 31 July 2024. Daily BTC candles start on 19 August 2020, but every bar before 26 February 2023 has zero volume and zero trades. A window older than the cap returns an empty array, not an error.

How do I get Hyperliquid funding rate history?

Use the public fundingHistory info request and page forward by timestamp. Each response holds at most 500 rows. On 11 November 2026 the full BTC history was 30,139 rows in 61 calls, starting 12 May 2023. Funding was paid every 8 hours until 8 June 2023 and hourly after that, with three single hours missing. Dwellir does not sell funding or open interest history as a separate dataset.

Where does Hyperliquid store historical data?

In two requester-pays S3 buckets. hyperliquid-archive (us-east-1) holds hourly L2 book snapshot files per coin and daily asset context CSVs. hl-mainnet-node-data (ap-northeast-1, Tokyo) holds node output: node_fills_by_block and two older fill formats, replica_cmds, explorer_blocks and misc_events_by_block. Hyperliquid's docs say hyperliquid-archive is uploaded approximately once a month, with no guarantee of timely updates, and state no cadence for the node data bucket.

Can a Hyperliquid node give me past data?

No. A non-validating node writes fills, order statuses, raw book diffs and other outputs from the first block it applies, and its local info server does not answer historical time series queries. Anything before the day you start it has to come from S3 or an archive. The node also needs 16 vCPUs, 128 GB of RAM and a 500 GB SSD at minimum.

How do I get Hyperliquid order book history at the order level?

Hyperliquid's own S3 only has aggregated L2 snapshots. Order-level (L4) history needs a starting state plus every later book change. Dwellir's archive has node_raw_book_diffs_by_block and node_order_statuses_by_block from 2026-01-22, and periodic_abci_states and generated orderbook_snapshots from 2026-04-14. A snapshot plus the diffs that follow rebuilds the full book at any block after 2026-04-14.

Does Dwellir sell Hyperliquid historical data through an API?

Partly. Candles at 1s, 1m and 5m and indexed fills are queryable over the Hyperliquid Index API, included in Dwellir plans from $49/month, back to 2025-07-27. The raw node archive (replica_cmds, fills, order statuses, book diffs, ABCI states, snapshots) is delivered as files through a read-only S3 key, priced per dataset by email. There is no query API over the raw archive.

Get the data

The Hyperliquid historical data page lists every prefix with its start date, compressed size and file count, has a date-range size estimator, and explains how to request access. To ask for a dataset, email support@dwellir.com with the prefix, date range and format. For candles and indexed fills, create a Dwellir account and use the Hyperliquid Index API.