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 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 on PyPI. 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

# Authenticate (one-time)
keel auth login

# Save a strategy on the platform
STRATEGY_ID=$(keel strategy compose --source-file my_strategy.py --name my_strategy --format json | jq -r '.strategy_id')

# Backtest — Keel handles the HL data pull and caching server-side
BT_ID=$(keel backtest run "$STRATEGY_ID" \
  --start-date 2024-08-15 \
  --end-date   2026-02-27 \
  --format json | jq -r '.run_id')

# Pull the summary
keel backtest summarize "$BT_ID" --format json

Under the hood Keel stores a 1-minute grid derived from every trade on the venue (March 2025 onward) that serves price at 5 minutes and coarser and feeds the order-flow loaders, plus 15-minute OHLCV for the earlier history, 1-hour settled funding (hourly is that series’ real cadence, so hourly is what it stays), and the venue-state series — open interest, premium, predicted funding — which the loaders serve on your strategy’s own clock, all partitioned by asset for fast selective reads. You access the data indirectly: the components in your pipeline (price, funding, OI, premium and order-flow loaders) consume the relevant series; the backtest result you pull with keel backtest summarize 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 from the API. The info endpoint does not serve historical tick or L2 data. Keel’s order-flow series come from its own trade-derived 1-minute bars, not from this endpoint; if you go direct, tick history means recording the websocket yourself going forward.