Authentication

Machine clients use a bearer API key. Browser users sign in through Clerk and need an active Proof organization membership.

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. Use bearer authentication when possible because it works with the CLI and common HTTP clients.

Organization scope

Proof gets the organization from the key. It ignores organization IDs sent by a machine client. Repository and Job lookups stay within the key's organization.

Browser sessions and organizations

The web app uses Clerk for sign-in and organization selection. A valid Clerk session alone does not give access to product data. Proof also requires matching active user, organization, and membership records for every protected page or API route.

Owners and administrators can change organization settings and view SSO status. Members and viewers can inspect product QA data based on their role.

Authentication errors

Status	Meaning
`401`	The API key, sign-in session, or membership is missing or invalid.
`403`	Role rules or same-origin rules block the signed-in request. Same-origin rules block browser requests from another site.
`404`	The resource is not in the organization you can access. Proof does not reveal whether it exists elsewhere.

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.