Quick Start

Start with one authenticated BTC order book call, confirm the payload, then branch into the interface that matches the job.

First call
BTC order book
Auth
X-API-Key
Then
Playground, REST, WebSocket, SDKs

Start with one live BTC order book request. It confirms account setup, X-API-Key auth, Hyperliquid routing, and the response shape. Then pick the interface that fits.

One request first

Create a key, send BTC, keep the request_id.

Preflight

Account createdAPI key copiedHyperliquid BTC route selected

Shortest path

Three moves. No client switch until the response lands.

  1. 01
  2. 02
    Client

    Send one live BTC order book request

    Use the Hyperliquid BTC call first so auth, route shape, and symbol naming stay simple.

    GET /v1/hyperliquid/orderbook/BTC

    HTTP 200 with a data payload

  3. 03
    Client

    Keep the first good response as the baseline

    Do not branch into Playground, WebSocket, or SDKs until you have one known-good request and response pair.

    Known-good payload plus request_id

Run the request

Use X-API-Key against the Hyperliquid order book.

cURLBash
API_BASE="https://api.0xarchive.io/v1/hyperliquid"
# Live order book request
curl --request GET \
--url "${API_BASE}/orderbook/BTC" \
--header "X-API-Key: 0xa_your_api_key"
PythonPython
import requests
API_BASE = "https://api.0xarchive.io/v1/hyperliquid"
# Live order book request
response = requests.get(
f"{API_BASE}/orderbook/BTC",
headers={"X-API-Key": "0xa_your_api_key"},
timeout=10,
)
data = response.json()["data"]
print(data["mid_price"])
TypeScriptTypeScript
const API_BASE = "https://api.0xarchive.io/v1/hyperliquid";
// Live order book request
const response = await fetch(`${API_BASE}/orderbook/BTC`, {
headers: { "X-API-Key": "0xa_your_api_key" },
});
const { data } = await response.json();
console.log(data.mid_price);
RustRust
use reqwest::Client;
let client = Client::new();
let api_base = "https://api.0xarchive.io/v1/hyperliquid";
// Live order book request
let orderbook = client
.get(format!("{api_base}/orderbook/BTC"))
.header("X-API-Key", "0xa_your_api_key")
.send().await?
.json().await?;
println!("BTC mid price: {}", orderbook["data"]["mid_price"]);

Checks

What to confirm

Account, auth, route, symbol, and order book schema clear in one response.

Endpoint path

GET /v1/hyperliquid/orderbook/BTC

Auth header

X-API-Key: 0xa_your_api_key

Payload checks

bidsBest bid levels return first.
asksBest ask levels return first.
mid_priceOne field for price context.
meta.request_idKeep it for QA or support traces.

Confirm the payload

Look for four fields, then move on.

Status

HTTP 200

The request succeeds without changing interfaces or transports.

Book

bids + asks

You should see both sides of the book under data.

Summary

mid_price + spread

These fields confirm you are reading the normalized order book response.

Trace

request_id

Keep the request ID for debugging and support handoff.

Read the response

Confirm the normalized order book fields and keep the request_id with the first good payload.

Example payloadJSON
{
"success": true,
"data": {
"coin": "BTC",
"timestamp": "2026-01-01T12:00:00Z",
"bids": [
{
"px": "42150.50",
"sz": "2.5",
"n": 5
}
],
"asks": [
{
"px": "42151.00",
"sz": "1.8",
"n": 3
}
],
"mid_price": "42150.75",
"spread": "0.50",
"spread_bps": "1.19"
},
"meta": {
"count": 1,
"request_id": "req_abc123"
}
}

Finish setup

Lock the boring parts down once the first request works.

1

Store the key in the environment you will actually use

Move the key out of copied command history and into the shell, app config, or secret manager that owns the next job.

2

Keep one known-good payload

Save the first successful response or request_id so later changes can isolate transport or client issues instead of re-debugging auth.

3

Branch into the right interface

After the first response is stable, pick the interface that fits: browser, REST reference, WebSocket, SDK, or wallet-managed automation.

Where to go next