Authentication

Two credentials exist on the platform — don't mix them up:

Credential	Used against	How
API key	rpc.lab.au.ro (RPC traffic)	apikey: <key> header
JWT (from login/register)	api.lab.au.ro (management API)	Authorization: Bearer <token> header

API keys

The header

Every RPC request must carry the key in the apikey header:

curl -X POST https://rpc.lab.au.ro/eth \
  -H "apikey: $YOUR_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'

Requests without a key get HTTP 401; an unknown key gets 401 as well (see Errors).

Lifecycle

Action	Call
Create	POST /api/v1/projects/{projectID}/keys → returns the full key once
List	GET /api/v1/projects/{projectID}/keys → prefixes only, never full keys
Revoke	DELETE /api/v1/keys/{id} → immediate, irreversible

Keys are stored hashed server-side. If you lose a key, revoke it and create a new one — there is no recovery path by design.

Show-once semantics

The create response is the only moment the platform knows the plaintext:

{
  "id": "b66e9039-0100-4fb2-a463-a3fcacd7d97b",
  "key": "c30b0f89...",        // full key — capture it now
  "key_prefix": "c30b0f89",    // what listings show later
  "description": "production backend"
}

Rotation

Zero-downtime rotation is two overlapping steps:

1. Create a new key in the same project, deploy it to your app.
2. Revoke the old key (DELETE /api/v1/keys/{old-id}).

Both keys are valid during step 1 — there is no forced single-key window.

Per-project chain scoping

A project's chains field (default null = all chains) can restrict which chains its keys may call:

curl -X PUT https://api.lab.au.ro/api/v1/projects/$PROJECT_ID \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"name":"My first project","chains":["eth","btc"]}'

A key calling a chain outside the scope receives JSON-RPC error -32011 (chain "xyz" not in project scope). Aliases are understood — scoping ethereum also covers the /eth path.

Management API (JWT)

POST /api/v1/auth/register and POST /api/v1/auth/login both return {"token": "..."}. Tokens are short-lived; refresh happens via the refresh_token HTTP-only cookie (POST /api/v1/auth/refresh), which the dashboard handles automatically.

Accounts support TOTP 2FA, passkeys and recovery codes — manage them in the dashboard under Settings, or via /api/v1/auth/mfa/*. When MFA is enabled, login returns {"mfa_required": true} with a partial token to complete via POST /api/v1/auth/mfa/verify.