Free Crypto Data API

Start with free BTC and km:US500 coverage, then upgrade only when you need all symbols, replay, or order-level routes.

Free tier
BTC + km:US500
Upgrade for
All symbols and replay
Auth
X-API-Key

Use Quick Start when the immediate job is one live authenticated request. Get a known-good BTC response first, then branch into the interface that actually fits the work.

If you already know the job is browser-first, stream-first, or wallet-managed, skip straight to Playground, WebSocket, or Wallet Automation after the first request lands.

First live request

Clear account setup, auth, routing, and symbol naming in one pass.

Have this ready

Account createdAPI key copiedHyperliquid BTC route selected

Shortest path

This is the cleanest route from zero to one known-good live response.

  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

Send one authenticated request against the Hyperliquid BTC order book.

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"

Why this path

Use the BTC call as the baseline

It proves account setup, X-API-Key auth, Hyperliquid routing, and the normalized order book shape — no client or transport changes needed yet.

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

Check the response shape, 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.

Pick the next interface

Branch based on the real operating model, not on whatever tool you opened first.

Where to go next