API Key Management
Why every key-management endpoint rejects API key auth — and what to do instead.
These endpoints reject API-key authentication and return 403. Only the
JWT auth used by the wallet-signed web UI session is accepted —
API-key clients cannot manage their own keys programmatically.
This is intentional — it prevents privilege escalation. A READ_ONLY key
holder must not be able to mint themselves a TRADE or WITHDRAW key.
Endpoint table
| Method | Path | API key | UI |
|---|---|---|---|
POST | /v2/api-keys | 403 | ✓ |
GET | /v2/api-keys | 403 | ✓ |
PATCH | /v2/api-keys/:id | 403 | ✓ |
DELETE | /v2/api-keys/:id | 403 | ✓ |
Key management workflow
- Create a new key — sign in via the UI, sign the wallet challenge, generate the key, copy the secret.
- List existing keys — UI only.
- Revoke a key — UI, or contact the operations team.
If a key is compromised
- Revoke it from the UI immediately.
- Mint a fresh key with the minimum permission set.
- While you wait for full rotation, you can disable the IP whitelist match
from the UI (
PATCH) to lock the old key out of every IP except the new client host.