---
title: "Free Crypto Data API | 0xArchive Docs"
description: "Start with free BTC and km:US500 coverage, then upgrade only when you need all symbols, replay, or order-level routes."
canonical_url: "https://www.0xarchive.io/docs/free-crypto-data-api/"
markdown_url: "https://www.0xarchive.io/docs/free-crypto-data-api.md"
route: "/docs/free-crypto-data-api"
robots: "index, follow"
generated_from: "prerendered_html"
---

# 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

Copy Markdown

[Open Quick Start](https://www.0xarchive.io/docs/quick-start/)

[View pricing](https://www.0xarchive.io/pricing/)

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 created

API key copied

Hyperliquid BTC route selected

### Shortest path

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

1. 01 You Create the account and mint one key Start at [0xArchive.io/signup](https://www.0xarchive.io/signup/), then create one API key in the [dashboard](https://www.0xarchive.io/dashboard/). One dashboard-managed API key
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.

cURL

Python

TypeScript

Rust

Copy

```
API_BASE="https://api.0xarchive.io/v1/hyperliquid"
# Live order book requestcurl --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

bids

Best bid levels return first.

asks

Best ask levels return first.

mid_price

One field for price context.

meta.request_id

Keep 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 payload

JSON

Copy

```
{  "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.

[Authentication Use this when you need the key lifecycle rules or the wallet-auth branch.](https://www.0xarchive.io/docs/authentication/)

[Hyperliquid REST API Open the Hyperliquid route reference for parameters, credits, candles, funding, liquidations, and adjacent endpoints.](https://www.0xarchive.io/docs/rest-api/hyperliquid/)

[WebSocket API Switch here when the next job is live streaming, replay, or gap recovery.](https://www.0xarchive.io/docs/websocket/)

### Where to go next

[Playground Run the same request in the browser when you want a fast live payload check without leaving docs.](https://www.0xarchive.io/docs/playground/)

[SDKs Move the same request into the official Python, TypeScript, or Rust client.](https://www.0xarchive.io/docs/sdks/)

[Wallet Automation Use this path when scripts need wallet-managed signup, keys, or x402 billing.](https://www.0xarchive.io/docs/wallet-automation/)

[Guides Go deeper when venue choice, route cost, and data continuity become design constraints.](https://www.0xarchive.io/docs/guides/)