SIWE verification - 0xArchive

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

Create a SIWE challenge

Use /v1/auth/web3/challenge in the REST reference.

Sign with the wallet

The wallet signs the challenge outside the API.

Verify the signature

Send the signed SIWE message to POST /v1/auth/web3/verify.

Issue API access

Use the web3 account routes documented in OpenAPI when the confirmed wallet should receive an X-API-Key credential.

Store resulting credentials safely

Treat generated keys like any other API key.

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.

Authentication

API-key auth for standard clients.

REST API

Open the generated SIWE route reference.

​Flow

​When To Choose SIWE Verification

​Market Data vs Account Verification

​Implementation Checks

​Generated-Client Rule