Standard server and script clients should use dashboard-created API keys. Wallet automation is for systems that need to create or manage access from a wallet flow.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.
Flow
Exchange for managed access
Use the web3 key routes documented in OpenAPI for wallet-managed key operations.
When To Choose Wallet Automation
Use wallet automation when the application needs the user wallet to be part of the access lifecycle: signup, challenge signing, managed key creation, payment-aware flows, or account automation that should be tied to wallet ownership. Do not use it for ordinary backend jobs, notebooks, cron tasks, or coding-agent sessions. Those should use dashboard-created API keys. Keep the wallet-signing step outside 0xArchive API calls. The API can issue and verify challenge flows, but the wallet owner signs through the wallet environment. After a managed key exists, treat it like any other credential: store it in a secret manager, rotate it when access changes, and avoid sending it to a browser or prompt transcript.Market Data vs Account Automation
| Workflow | Default path |
|---|---|
| Server REST calls | Create a dashboard key and send X-API-Key |
| WebSocket clients | Configure the same API key during connection setup |
| SDK, CLI, MCP, and Skill jobs | Use environment variables backed by dashboard-created keys |
| Coding-agent route tests | Use a scoped session key, keep it out of prompt transcripts, and log request_id |
| Wallet-owned signup | Create a SIWE challenge, sign in the wallet, then exchange through the wallet-auth routes |
| Wallet-managed keys | Use wallet automation when key lifecycle should follow wallet ownership |
| Payment-aware account flows | Use wallet automation only for account and access actions, not ordinary market-data reads |
Implementation Checks
Read the generated REST reference for the exact wallet-auth routes before coding. Preserverequest_id in failures, separate wallet identity from API-key storage, and route ordinary market-data calls back through the same X-API-Key behavior used by the rest of the portal.
Generated-Client Rule
Wallet automation is an account/access workflow, not the default market-data integration path. Generated examples should use dashboard API keys for ordinary server, CLI, SDK, MCP, Skill, and WebSocket jobs unless the user specifically asks for wallet-managed access.Authentication
API-key auth for standard clients.
REST API
Open the generated wallet-auth route reference.