Authentication Overview

Two authentication contexts

Verdict has two distinct authentication surfaces:

• Dashboard / web app — session-based. Sign in once via Privy (email magic-link, Google, or wallet signature); your session cookie keeps you logged in until you sign out.
• API — stateless. Every request carries an API key in the Authorization: Bearer ... header. Keys are issued from your dashboard.

Dashboard sign-in (Privy)

We use Privy as the auth provider. Three sign-in methods are supported, all interchangeable on a single account:

• Email magic link — one-time link sent to your inbox; an embedded wallet is provisioned behind the scenes.
• Google sign-in — OAuth; also provisions an embedded wallet.
• Wallet connection — signs an EIP-191 message with your wallet's private key.

After sign-in you land on /dashboard. The same account can link multiple wallets; one is designated primary for payment attribution.

API authentication

Every API request must include:

Authorization: Bearer verdict_pk_<your-key>

Keys are created, labelled, rotated, and revoked from /dashboard/keys. The plaintext is shown once at creation and is never recoverable — copy it to your secrets manager immediately. The dashboard stores only a hashed prefix for display. See the API Keys guide for rotation patterns and storage best practices.

Auth failure responses

Auth-related failures return one of these error codes:

• invalid_key (401) — header malformed or key doesn't exist.
• expired_key (401) — Pro subscription expired.
• disabled_key (401) — key was rotated or revoked.
• tier_required (403) — key is valid but the endpoint requires a higher tier.

See Errors & Troubleshooting for the full response shape and fixes.