> ## Documentation Index
> Fetch the complete documentation index at: https://docs.0xarchive.io/llms.txt
> Use this file to discover all available pages before exploring further.
# API playground
> Use the interactive API playground and curl examples to inspect 0xArchive REST routes, parameters, responses, authentication, and schemas.
Endpoint Reference includes an interactive playground for endpoint calls. Use it for quick payload checks, then move stable workflows into SDK, CLI, or application code.
Free tier, no card
Get a key and run a real call
New accounts start free, no card required. Create a key in the dashboard and paste it into any example here.
Start with a low-risk market-state route such as a Hyperliquid order book.
Use the `X-API-Key` auth control in Endpoint Reference.
Inspect `success`, `data`, and `meta.request_id`.
Move the same request into curl, Python, JavaScript, or Go.
Browse OpenAPI-backed endpoint pages.
Run the same flow from your terminal.
## Playground Review Checklist
Use the playground result to create a small implementation note before copying code into a client.
| Field | Capture |
| ----------------- | ------------------------------------------------------------------------------------------- |
| Endpoint | Method, route, symbol, and query parameters from Endpoint Reference |
| Auth state | Whether `X-API-Key` was supplied through the playground control or through copied curl |
| Response envelope | `success`, `data`, `error`, and `meta.request_id` behavior |
| Generated example | The curl, Python, JavaScript, or Go example copied from the same endpoint page |
| Client gap | Retry, pagination, request-ID logging, freshness, or limit behavior still missing from code |
| Next surface | SDK, CLI, WebSocket, OpenAPI codegen, or Data Catalog when the job is file delivery |
If the browser run fails but the generated curl works, continue from curl and keep the browser limitation out of the application design. If both fail, keep the status, error code, route, parameters, and request ID together before debugging the client. The public website links to this docs playground instead of maintaining a separate static endpoint tester.
## What The Playground Is Good For
Use the playground to confirm route shape, auth, parameters, and response fields before writing code. It is especially useful when you are deciding between route families: compare a Hyperliquid core example, a Spot pair, a HIP-3 namespaced symbol, a HIP-4 outcome, and a Lighter symbol before committing the route to a client.
The playground is not a replacement for production error handling. After you copy an example into code, add retries, request-ID logging, pagination, data-quality checks, and a clear key-management path. If browser execution is limited by an auth or CORS environment, the generated curl example is still the stable fallback because it shows the exact method, path, parameters, and `X-API-Key` header.
## Safe Test Pattern
Start with low-cost market-state routes, then move to historical windows. Keep query parameters narrow while testing: one symbol, one route, one time window, and a small `limit`. Once the response is understood, move to CLI, SDK, REST code, or OpenAPI codegen for repeatable workflows.
## Review Rule
Do not treat a playground success as production readiness. It confirms that one route can respond with the provided key and parameters. Production code still needs key management, retries, request-ID logging, pagination, limit handling, and data-quality gates where downstream use depends on correctness.