Developers
Authentication
Five credential types map to five jobs. Each request is scoped fail-closed — a key can only do what its class allows.
Credential types
| Credential | Used by | What it can do | Notes |
|---|---|---|---|
| Publishable (pk_) | Browser | Consent capture from the browser (the embed). Safe to ship to the client. | pk_test_… / pk_live_… — the env is baked into the key. |
| Secret (sk_) | Your server | Tenant API — capture, check, evidence, RoPA, breach, governance. | Server-only. Never ship to a browser. |
| Read-only (rk_) | Auditors | Read/verify endpoints for auditors and dashboards. | Least-privilege reads. |
| Operator | Platform | Tenant lifecycle + key minting (the platform owner). | Control-plane; tightly held. |
| Principal session | End-user | §11/§12 rights — minted by OTP / DigiLocker after verifying the data principal. | Sent as x-principal-token; 'step-up' required for erasure. |
How it's sent
Headers
Tenant / operator keys
Authorization: Bearer sk_live_… — the key encodes the tenant, role and environment. No other trust headers are needed.
Principal sessions
x-principal-token: <session> — a stateless signed token from the OTP/SSO ceremony. The route resolves the tenant from the token.
Publishable keys can only reach consent-capture endpoints; they can never act as a tenant or operator key. Test/live data is isolated by the key's environment.
Mint your first keys
Spin up a tenant, get pk_/sk_/rk_ keys scoped fail-closed, and wire principal sessions for §11/§12 rights.