> ## 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.

# SIWE verification

> Use SIWE wallet signatures to verify account ownership before issuing `X-API-Key` credentials or browser sessions.

Dashboard-created API keys are the default for servers, scripts, SDKs, CLI, MCP, Skill, REST, and WebSocket clients. SIWE verification is for account setup that needs a wallet signature before 0xArchive issues an `X-API-Key` credential or browser session.

0xArchive never requests or stores private keys or seed phrases. It does not hold funds, submit orders, approve transactions, or connect to exchange accounts. The wallet signs a message outside the API; the signed message confirms control of the address named in the challenge.

## Flow

<Steps>
  <Step title="Create a SIWE challenge">
    Use `/v1/auth/web3/challenge` in the REST reference.
  </Step>

  <Step title="Sign with the wallet">
    The wallet signs the challenge outside the API.
  </Step>

  <Step title="Verify the signature">
    Send the signed SIWE message to `POST /v1/auth/web3/verify`.
  </Step>

  <Step title="Issue API access">
    Use the web3 account routes documented in OpenAPI when the confirmed wallet should receive an `X-API-Key` credential.
  </Step>

  <Step title="Store resulting credentials safely">
    Treat generated keys like any other API key.
  </Step>
</Steps>

## When To Choose SIWE Verification

Use SIWE verification when account setup or credential issuance must be tied to wallet ownership. Do not use it for 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 through `/v1/auth/web3/challenge` and `POST /v1/auth/web3/verify`, but the wallet owner signs through the wallet environment. After an `X-API-Key` credential 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 Verification

| 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 verify wallet ownership                     |
| SIWE-confirmed `X-API-Key` credentials | Use SIWE verification when credential issuance should be tied to wallet ownership             |
| Account access flows                   | Use SIWE verification only for account and credential actions, not ordinary market-data reads |

Private keys should never be sent to 0xArchive, checked into examples, or copied into agent prompts. SIWE verification cannot move funds, hold assets, place orders, approve transactions, or connect to an exchange account. If a team only needs a normal API key, use the dashboard and keep the integration on the standard authentication path.

## Implementation Checks

Read Endpoint Reference for the exact SIWE routes before coding. Preserve `request_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

SIWE verification is an account/access workflow, not the default market-data integration path. Generated examples should use dashboard API keys for server, CLI, SDK, MCP, Skill, and WebSocket jobs unless the request specifically asks for wallet-owned account verification.

<CardGroup cols={2}>
  <Card title="Authentication" icon="key-round" href="/authentication">
    API-key auth for standard clients.
  </Card>

  <Card title="REST API" icon="square-terminal" href="/rest-api">
    Open the generated SIWE route reference.
  </Card>
</CardGroup>