Authentication

API keys, dashboard wallet sessions, and provider node tokens.

API keys

Every API request carries an Authorization: Bearer ... header. The token looks like gpu_ followed by 48 hex characters and is bound to the wallet that signed it in on the dashboard.

http
Authorization: Bearer gpu_a1b2c3d4e5f6...

Issuing a key

Keys are minted from /app after connecting an EVM wallet and signing a one-time message Sign in to GPU: <nonce>. There is no email signup; one wallet owns one key.

Dashboard wallet sessions

The signed message creates an HttpOnly cookie gpu_session that's valid for 24 hours. The cookie lets the dashboard call private endpoints (/api/keys, /api/claim, /api/credits) without re-prompting on every refresh.

Provider node tokens

Provider nodes don't use the bearer key. They register via POST /api/providers/register and receive a node id, which they then use as a path parameter in subsequent long-poll and submit calls. The node id is bound to the wallet supplied at registration so rewards always go to the right place.

Never expose API keys in front-end code
The bearer key gives access to your credit balance. The dashboard's own test-chat doesn't store the key in the page — it lives in a React state derived from the session cookie via /api/keys.