Authentication

Machine clients use a bearer API key. Browser users authenticate through Clerk and are authorized against Proof's synchronized organization memberships.

Authenticate machine requests

Create a revocable key in the organization's API access page and send it in the standard Authorization header:

http

Authorization: Bearer proof_sk_your_organization_key
Content-Type: application/json

The API also accepts x-proof-api-key, but bearer authentication is recommended because it works consistently with the CLI and common HTTP clients.

Organization scope

Proof derives the tenant from the key and ignores organization identifiers supplied by a machine client. Repository and run lookups are filtered to the key's organization.

Browser sessions and organizations

The web application uses Clerk for authentication and organization selection. A valid Clerk session does not grant product data by itself. Proof requires matching active user, organization, and membership rows in its database on every protected Server Component or Route Handler.

Owners and administrators can change organization settings and view SSO state. Members and viewers can inspect product QA data according to the current role policy.

Authentication errors

Status	Meaning
`401`	Missing or invalid API key, signed-out session, or unsynchronized membership.
`403`	Authenticated request rejected by same-origin or role policy.
`404`	The resource does not exist in the authorized organization. Proof avoids revealing cross-tenant resource existence.

Handle keys safely

Keep API keys in a password manager, CI secret store, or local environment variable.
Never commit .env.local or the CLI configuration file.
Revoke and replace a key after suspected exposure.
Use separate keys for each person or automation client.
Use signed, expiring artifact links when sharing evidence outside the dashboard.