Hyperliquid OHLCV data — web app, Python SDK, CLI

The three paths

Primary: the Keel web app. Sign up, compose a pipeline in the visual builder, click Run Backtest — HL data and caching are handled server-side and you never touch a raw bar. This is the right path if you want to run a strategy and read a tearsheet, not maintain a data store.

Direct: the official Python SDK. The hyperliquid-python-sdk wraps the HL info endpoint directly — good if you want raw control over what you fetch, no caching opinion, no backtest-engine assumptions.

Agent: the keel-trade CLI. For terminal or AI-agent driven workflows, keel-trade (v0.1.6 on PyPI) runs the same backtests against the same managed data — no local cache, no raw bar plumbing.

Direct option: the official Python SDK

The SDK is installable from PyPI and ships against the live HL mainnet endpoint. The minimal pull for a single asset:

# pip install hyperliquid-python-sdk
from hyperliquid.info import Info
from hyperliquid.utils import constants
import time

info = Info(constants.MAINNET_API_URL, skip_ws=True)

# 15-minute candles for BTC, last ~30 days
end = int(time.time() * 1000)
start = end - 30 * 24 * 60 * 60 * 1000
candles = info.candles_snapshot(
    name="BTC",
    interval="15m",
    startTime=start,
    endTime=end,
)
# candles -> list of {t, T, s, i, o, h, l, c, v, n}

Each candle is a dict with t (open time ms), T (close time ms), o/h/l/c (prices), v (volume) and n (trade count). For the full HL perp universe, query info.meta() first to get the list of asset names, then loop over them with your own rate-limiting. The info endpoint is rate-limited per IP — back off on 429s and cache to disk after the first pull.

Agent option: the Keel CLI for terminal-driven backtests

If you drive Keel from a terminal or an AI agent — Claude Code, an MCP server, a research notebook — the keel-trade CLI runs the same backtests the web app does, server-side. Published as keel-trade v0.1.6 on PyPI on 2026-04-04. Install with pipx; authenticate once; submit a backtest. The HL data pull and caching are handled server-side, so you do not maintain a local data store.

# pipx install keel-trade   (keel-trade v0.1.6 on PyPI)

# Authenticate (one-time)
keel auth login

# Create a strategy on the platform
keel strategy create my_strategy.py

# Backtest — Keel handles the HL data pull and caching server-side
keel backtest run str_abc123 \
  --start-date 2024-08-15 \
  --end-date   2026-02-27

# Pull the results
keel backtest results bt_xyz789

Under the hood Keel stores OHLCV at 15-minute resolution, funding at 1-hour resolution, and open interest at 1-hour resolution, partitioned by asset for fast selective reads. You access the data indirectly: the components in your pipeline (price data loader, funding data loader, OI loader) consume the relevant series; the backtest result you pull with keel backtest results contains the equity curve, attribution, and per-asset stats.

Caveats worth knowing

• History varies per asset. BTC and ETH go back to the HL public launch; a newer listing might have weeks. Check info.meta() for the listing universe and run your own history audit before assuming uniform coverage.
• Newer listings have short funding history. If a regime detector needs 20 bars of funding context and the asset has 10, it will produce nothing useful for that asset until the history fills in. Keel does not impute.
• Rate limits on the HL public API. The info endpoint is per-IP rate-limited. Acceptable for ad-hoc research, painful for a full-universe historical pull in a tight loop. Cache and back off on 429s.
• Funding and OHLCV are separate endpoints. The SDK exposes them separately; the CLI fetches both. Keep them as separate series rather than merging — the cadences differ (15-minute price, hourly funding).
• Bar-level only. The info endpoint does not serve historical tick or L2 data. Live websockets expose trades and order-book deltas in real time, but reconstructing tick history requires recording the stream yourself going forward.