> ## 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 keys and credential safety

> Create, store, rotate, and protect API keys for 0xArchive REST, WebSocket, SDK, CLI, Skill, and API-key agent workflows; hosted MCP uses client-managed OAuth.

Create an API key, keep it out of code and browsers, and rotate it when access changes. One key works for the REST API, WebSocket, the SDKs, the CLI, the Agent skill, and other API-key agent workflows. The hosted MCP server is the exception: it uses OAuth managed by your client and needs no 0xArchive API key.

## Key lifecycle

<Steps>
  <Step title="Create a key in the dashboard">
    Create and manage keys in the [0xArchive dashboard](https://0xarchive.io/dashboard?utm_source=docs\&utm_medium=referral\&utm_campaign=docs_referral\&utm_content=authentication_dashboard_link). New accounts start on the Free tier.
  </Step>

  <Step title="Store it outside source control">
    Load the key from an environment variable or secret manager. Never place it in checked-in code, notebooks, prompts, logs, screenshots, or public issue text.
  </Step>

  <Step title="Pass it the way each client expects">
    The REST API takes the key in an HTTP header. WebSocket takes it during connection setup. The SDKs, CLI, Agent skill, and API-key agent workflows read it from their runtime environment. The hosted MCP server uses the client's built-in OAuth flow instead and needs no 0xArchive API key.
  </Step>

  <Step title="Rotate when access changes">
    Replace a key when a workflow, machine, environment, or teammate no longer needs access.
  </Step>
</Steps>

## Where each client reads the key

| Client | How it gets the key |
| - | - |
| REST API | Read `OXARCHIVE_API_KEY` from the runtime environment and send it as `X-API-Key`. See [REST authentication](/rest-api/authentication) |
| WebSocket | Send the same API key during connection setup. See [WebSocket connection](/websocket/connection) |
| SDKs | Pass the key when you construct the client. See [SDK installation](/sdks/installation) |
| CLI | Export `OXA_API_KEY` for `oxa` commands. See [CLI](/cli) |
| Agent skill | Pass `OXARCHIVE_API_KEY` through the host environment or secret store. See [Agent skill](/skill) |
| Hosted MCP server | OAuth managed by your client; no 0xArchive API key. See [MCP server](/mcp-server) |
| Browser applications | Call your own backend; never expose a 0xArchive key to users. See [WebSocket connection](/websocket/connection) |

## Separate keys by environment

Use a different key for local development, CI, staging, production, and agent or tooling work where you can. Separate keys make rotation and incident diagnosis safer, and a leaked development key cannot expose a production workflow.

## Keep keys out of the browser

Do not embed a 0xArchive API key in frontend JavaScript or ship it to a browser. A browser application should call a backend you control. That backend holds the key, enforces user-level access, and keeps the credential out of browser URLs, telemetry, and copied prompts.

## Wallet verification

SIWE verifies wallet ownership for account and credential flows. It is not the default authentication method for market-data calls. Existing-wallet verification starts with `/v1/auth/web3/challenge`, then submits the signed message to `POST /v1/auth/web3/verify`. Follow [SIWE verification](/wallet-automation) for the complete wallet flow.

0xArchive never requests private keys or seed phrases, cannot move funds, cannot approve transactions, and cannot place or cancel venue orders.

## Next step

Send your first authenticated request in the [Quickstart](/quickstart).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.