Historische Daten von Hyperliquid abrufen: API-Methoden

• hyperliquid historical data

• hyperliquid data api

• hyperliquid historische daten

• hyperliquid candlestick daten

• hyperliquid funding rate history

Daten sind die Grundlage jeder quantitativen Analyse. Egal ob du Trading-Strategien backtestest, Funding-Rate-Muster untersuchst oder Markt-Mikrostruktur analysierst: Du brauchst verlässliche und möglichst vollständige historische Daten. Hyperliquid ist eine On-Chain-Perpetuals-Börse und stellt über seine REST API verschiedene historische Datenschnittstellen bereit, darunter K-Lines bzw. OHLCV-Daten, Funding Rates, Trades, User Fills und Liquidation Events.

In diesem Artikel gehen wir Schritt für Schritt durch die wichtigsten Methoden zum Abrufen historischer Hyperliquid-Daten, relevante Parameter, Pagination-Strategien und Best Practices für lokale Speicherung. Für Schnittstellen, die Authentifizierung oder Signaturen erfordern, kann eine OneKey Hardware Wallet dabei helfen, Signaturen sicher bereitzustellen.

Überblick: Hyperliquid Historical Data API

Laut Hyperliquid-Dokumentation laufen viele historische Datenabfragen über den Endpoint POST /info. Welche Daten du bekommst, wird im Request Body über das Feld type gesteuert.

Alle Zeitstempel werden als Unix-Timestamps in Millisekunden verwendet, also als 13-stellige Integer.

K-Line-Daten bzw. OHLCV abrufen

Request-Format

import requests

BASE_URL = "https://api.hyperliquid.xyz"

def fetch_candles(coin, interval, start_ms, end_ms):
    """
    coin      : Trading-Pair, z. B. "BTC"
    interval  : Zeitintervall, z. B. "1m", "5m", "1h", "1d"
    start_ms  : Startzeit als Millisekunden-Timestamp
    end_ms    : Endzeit als Millisekunden-Timestamp
    """
    payload = {
        "type": "candleSnapshot",
        "req": {
            "coin":      coin,
            "interval":  interval,
            "startTime": start_ms,
            "endTime":   end_ms
        }
    }

    resp = requests.post(f"{BASE_URL}/info", json=payload)
    resp.raise_for_status()
    return resp.json()

# Beispiel: BTC 1h-Candles der letzten 7 Tage abrufen
import time

end_ms   = int(time.time() * 1000)
start_ms = end_ms - 7 * 24 * 3600 * 1000
candles  = fetch_candles("BTC", "1h", start_ms, end_ms)

Rückgabefelder

Jede Candle enthält typischerweise die folgenden Felder. Die finalen Feldnamen solltest du immer mit der offiziellen Dokumentation abgleichen:

• t: Startzeit der Candle, Millisekunden-Timestamp
• o: Open Price
• h: High Price
• l: Low Price
• c: Close Price
• v: Volume
• n: Anzahl der Trades

Pagination-Strategie

Ein einzelner Request hat üblicherweise ein Limit für die Anzahl zurückgegebener Datensätze. Für längere Zeiträume solltest du den Zeitraum in kleinere Abschnitte aufteilen und die Daten schrittweise abrufen.

def fetch_candles_paginated(coin, interval, start_ms, end_ms, page_size_ms):
    """
    Teilt den Zeitraum in mehrere Segmente auf, ruft sie einzeln ab
    und führt die Ergebnisse zusammen.

    page_size_ms: Zeitspanne pro Segment in Millisekunden,
                  passend zum gewählten interval wählen.
    """
    all_candles = []
    cursor = start_ms

    while cursor < end_ms:
        batch_end = min(cursor + page_size_ms, end_ms)
        batch     = fetch_candles(coin, interval, cursor, batch_end)
        all_candles.extend(batch)

        if not batch:
            break

        # Nächste Seite ab Timestamp der letzten Candle + 1 starten
        cursor = batch[-1]["t"] + 1

        # Kurze Pause, um Rate Limits zu vermeiden
        time.sleep(0.2)

    return all_candles

Funding-Rate-Historie

Funding Rates sind ein zentrales Element von Perpetual Futures. Historische Funding-Daten sind besonders nützlich, wenn du Marktstimmung, Long/Short-Druck oder potenzielle Arbitrage-Setups untersuchst.

def fetch_funding_history(coin, start_ms, end_ms):
    payload = {
        "type": "fundingHistory",
        "req": {
            "coin":      coin,
            "startTime": start_ms,
            "endTime":   end_ms
        }
    }

    resp = requests.post(f"{BASE_URL}/info", json=payload)
    resp.raise_for_status()
    return resp.json()

Die Rückgabe enthält die Funding Rate für die jeweiligen Abrechnungsperioden sowie den zugehörigen Timestamp. Du kannst diese Daten unter anderem nutzen, um:

• Veränderungen im Long/Short-Sentiment zu analysieren
• extreme Marktstimmungs-Signale zu identifizieren
• historische Haltekosten von Perp-Positionen zu berechnen

User Fills und Order-Historie

Schnittstellen mit nutzerspezifischen Daten benötigen in der Regel eine Wallet-Adresse; manche Endpoints können zusätzlich eine Signatur oder Authentifizierung erfordern. Eine OneKey Hardware Wallet kann solche Signaturen sicher bereitstellen. Der Private Key bleibt dabei im Hardware-Secure-Element und wird nicht an dein Datenskript oder deinen Server weitergegeben.

def fetch_user_fills(address, start_ms, end_ms):
    payload = {
        "type": "userFills",
        "req": {
            "user":      address,
            "startTime": start_ms,
            "endTime":   end_ms
        }
    }

    resp = requests.post(f"{BASE_URL}/info", json=payload)
    resp.raise_for_status()
    return resp.json()

User Fills enthalten typischerweise Informationen wie Order-ID, Richtung, Ausführungspreis, Größe und Gebühren. Diese Daten sind wichtig, wenn du realisierte PnL berechnen, Slippage messen oder die Ausführungsqualität einer Strategie bewerten möchtest.

Liquidation-Daten

Marktweite Liquidation Events helfen dabei, Marktstruktur und extreme Marktphasen besser zu verstehen.

def fetch_liquidations(start_ms, end_ms):
    payload = {
        "type": "liquidations",
        "req": {
            "startTime": start_ms,
            "endTime":   end_ms
        }
    }

    resp = requests.post(f"{BASE_URL}/info", json=payload)
    resp.raise_for_status()
    return resp.json()

Solche Daten können für Analysen zu Liquidation Clusters, Volatilitätsspitzen oder Marktstress hilfreich sein. Sie sollten aber immer im Kontext von Preis, Open Interest und Funding betrachtet werden.

Daten speichern: CSV und Datenbank

Speicherung als CSV

Für schnelle Prototypen ist CSV oft die einfachste Lösung.

import csv

def save_candles_to_csv(candles, filepath):
    if not candles:
        return

    fieldnames = ["t", "o", "h", "l", "c", "v", "n"]

    with open(filepath, "w", newline="", encoding="utf-8") as f:
        writer = csv.DictWriter(f, fieldnames=fieldnames)
        writer.writeheader()

        for candle in candles:
            writer.writerow({k: candle.get(k, "") for k in fieldnames})

CSV eignet sich gut für erste Analysen in Python, Pandas oder Tabellenprogrammen. Für regelmäßige Backtests, mehrere Märkte oder inkrementelle Updates ist eine Datenbank meist robuster.

Speicherung in einer Datenbank

Für größere Datenmengen oder effiziente Abfragen bieten sich SQLite für lokale Setups oder PostgreSQL für produktionsnähere Umgebungen an.

import sqlite3

def init_db(db_path):
    conn = sqlite3.connect(db_path)
    conn.execute("""
    CREATE TABLE IF NOT EXISTS candles (
        coin     TEXT,
        interval TEXT,
        t        INTEGER,
        o        REAL,
        h        REAL,
        l        REAL,
        c        REAL,
        v        REAL,
        n        INTEGER,
        PRIMARY KEY (coin, interval, t)
    )
    """)
    conn.commit()
    return conn

def insert_candles(conn, coin, interval, candles):
    rows = [
        (coin, interval, c["t"], c["o"], c["h"], c["l"], c["c"], c["v"], c["n"])
        for c in candles
    ]

    conn.executemany(
        "INSERT OR IGNORE INTO candles VALUES (?,?,?,?,?,?,?,?,?)",
        rows
    )
    conn.commit()

Der Primary Key PRIMARY KEY (coin, interval, t) verhindert, dass dieselbe Candle mehrfach eingefügt wird. Das ist besonders praktisch, wenn du historische Daten regelmäßig ergänzt und inkrementelle Updates fährst.

Rate Limits und wichtige Hinweise

Die Hyperliquid API hat Limits für Request-Frequenzen. Maßgeblich ist immer die offizielle Dokumentation zum Zeitpunkt deiner Implementierung. In der Praxis helfen diese Regeln:

• Zwischen Loop-Requests eine kurze Pause einbauen, zum Beispiel 200–500 ms
• Exponential Backoff implementieren und bei HTTP 429 automatisch warten
• Große historische Backfills möglichst außerhalb von Peak-Zeiten durchführen
• Bereits geladene Daten lokal cachen, statt identische Zeiträume wiederholt anzufragen
• Fehler und leere Antworten sauber loggen, damit du Datenlücken später prüfen kannst

Vergleich mit anderen Datenquellen

Der Vorteil der nativen Hyperliquid API liegt darin, dass die Daten direkt von der Quelle kommen und für Hyperliquid-Märkte in der Regel die maßgebliche Referenz sind. Für Research-Projekte, die mehrere Börsen vergleichen, kannst du zusätzlich andere Quellen einbinden. Auch dYdX-Dokumentation und GMX-Dokumentation beschreiben historische Datenendpoints, wobei sich Request-Design und Datenmodell von Hyperliquid unterscheiden können. Die Grundkonzepte bleiben aber ähnlich: Candles, Trades, Funding, Orders und Liquidations.

Häufige Fragen

Q1: Was ist das kleinste Intervall für K-Line-Daten?

Laut Hyperliquid-Dokumentation unterstützt candleSnapshot mehrere Zeitintervalle, darunter Minuten-, Stunden- und Tagesintervalle. Welche interval-Werte konkret verfügbar sind, solltest du in der offiziellen Dokumentation prüfen. Bei ungültigen Parametern gibt die API eine Fehlermeldung zurück.

Q2: Wie weit reichen historische Daten zurück?

Grundsätzlich können Daten seit Verfügbarkeit des jeweiligen Markts über die API abrufbar sein. Der tatsächlich verfügbare Zeitraum hängt aber vom Listing-Zeitpunkt des Marktes und den konkreten Daten ab. Wenn für einen Zeitraum keine Daten existieren, gibt die API typischerweise ein leeres Array zurück.

Q3: Wie lange dauert es, große Mengen historischer Daten zu laden?

Das hängt von Zeitraum, Intervall, Pagination und Rate Limits ab. Bei 1h-Candles über einen längeren historischen Zeitraum kann ein vollständiger Abruf je nach Setup mehrere Minuten bis deutlich länger dauern. Sinnvoll ist daher: einmal sauber backfillen, in einer Datenbank speichern und danach nur noch inkrementell aktualisieren.

Q4: Welche Rolle spielt OneKey beim Datenabruf?

Öffentliche Marktdaten wie Candles oder Funding Rates kannst du in der Regel ohne Authentifizierung abrufen. Bei privaten Nutzerdaten wie historischen Fills oder Order-Daten kann eine Signatur erforderlich sein. Eine OneKey Hardware Wallet kann diese Signaturen sicher bereitstellen, ohne dass dein Private Key auf dem Rechner oder Server liegt, auf dem dein Datenskript läuft.

Q5: Wie gehe ich mit Datenlücken um?

Netzwerkfehler, API-Probleme oder unterbrochene Jobs können zu Gaps führen. Speichere deshalb nicht nur die Daten selbst, sondern auch Metadaten zu jedem Abruf, etwa Zeitraum, Markt, Intervall und Status. Scanne deine Datenbank regelmäßig nach fehlenden Zeitfenstern und lade diese Segmente gezielt nach. Für Backtests sind solche Checks wichtig, da Datenlücken Signale verfälschen können.

Praktischer Workflow mit OneKey Perps

Wenn du historische Daten analysierst und daraus konkrete Trading-Entscheidungen ableitest, brauchst du einen sauberen Übergang von Research zu Ausführung. OneKey Perps ist dafür ein praktischer Workflow innerhalb des OneKey-Ökosystems: Du kannst deine Datenanalyse separat durchführen und anschließend Perp-Trades in einer Wallet-Umgebung verwalten, bei der Self-Custody und Signaturkontrolle im Fokus stehen.

Wenn du OneKey noch nicht nutzt, kannst du OneKey herunterladen bzw. einrichten und OneKey Perps ausprobieren. Das ist kein Ersatz für eigenes Risikomanagement, aber ein sinnvoller Weg, um Analyse, Wallet-Sicherheit und Perps-Trading näher zusammenzubringen.

Fazit

Die historischen Datenendpoints von Hyperliquid liefern eine solide Basis für quantitative Research-Projekte. Mit wenigen Zeilen Python kannst du Candles, Funding Rates, User Fills und Liquidation-Daten abrufen, lokal speichern und für Backtests oder Marktanalysen nutzen. Für private, signaturpflichtige Daten kann eine OneKey Hardware Wallet zusätzliche Sicherheit bieten, weil der Private Key nicht an dein Skript weitergegeben wird.

Wenn du auf Basis deiner Analysen auch praktisch handeln möchtest, ist OneKey Perps ein naheliegender Einstiegspunkt, um Daten-Insights und Perp-Ausführung in einem sicherheitsorientierten Workflow zu verbinden.

Risikohinweis: Historische Daten zeigen nur vergangene Marktbedingungen und sagen zukünftige Ergebnisse nicht zuverlässig voraus. Quantitative Strategien können overfitten, und Live-Resultate können deutlich von Backtests abweichen. Perpetual-Futures-Trading ist risikoreich und kann zu Verlusten führen. Dieser Artikel dient nur dem technischen Lernen und ist keine Anlage-, Rechts- oder Finanzberatung.