Auth API

Base URL: /v1/auth. One page per operation — the request, the response, and the errors that operation can actually produce.

Your users, their sessions and the tokens your API verifies — without you running any of it.

Convention over configuration. Accounts are created by a code we email, a confirmed address is always required, passwords are optional and at least twelve characters. None of those are switches, because none of them have a second answer we would defend. Settings lists what is fixed and the four things that are still yours.

Every example uses three shell variables. Set them once and the rest of these pages paste straight into a terminal:

export BASE="https://<your-deployment>"
export PK="pk_live_…"
export SK="sk_live_…"

Both keys are on your project page in the studio. New here? Start with the quickstart.

There is no SDK yet. This HTTP API is the whole interface, so everything here is a request you can make with curl, fetch, or whatever your language uses. Nothing below assumes a client library, and no example calls one.

Your users are in their own database

Every project gets its own Postgres database. Not a schema, not a shared table with a project column — a separate database, in a region you choose.

This is the part worth understanding, because it is what you are buying. Isolation by convention means every query in our codebase has to remember a where clause, and one that forgets is a breach. Isolation by database means two customers' rows are never in the same query scope, so there is no clause to forget.

What follows from it:

• Your data is yours to point at. One project, one database, one connection.
• Nobody else's traffic is your problem. Separate compute per project.
• Point-in-time recovery is per project, not per platform.

The cost is honest and worth naming: a database that has been idle scales to zero, so the first sign-in after a quiet period pays a wake-up of a second or two. Steady traffic never sees it.

Both key kinds work here

Auth is the one API you can call from a browser, because signing in happens in one and there is nowhere else for it to happen.

A publishable key in a browser is safe because of the origin check. Register your app's origins in the studio; exact matches only, no wildcards. A project with no registered origins accepts no browser traffic at all, which is the right default for one whose owner has not named any.

Cross-origin calls from a registered origin allow credentials, so send credentials: "include" from fetch or the session cookie will not stick.

Each page below says which key its operation takes. Two of them — listing and deleting users — take a secret key only and answer no CORS at all.

The operations

Accounts and sessions

• Sign up — create an account with an emailed code
• Sign in — sessions, and how they end
• Verify email — confirming an address
• Reset a password — the forgotten-password flow

Other ways in

• Social login — Google and GitHub, with your own OAuth app
• Two-factor — TOTP and recovery codes
• Passkeys — WebAuthn, bound to your domain
• Enterprise SSO — OIDC and SAML 2.0
• Directory sync — SCIM provisioning

Managing what exists

• Organizations — workspaces inside your app
• Get users — list and page through accounts
• Delete users — by the person, or by you
• Settings — what is fixed, and what you decide

Reference

• Tokens and JWKS — verifying without calling us
• Limits and states — rate limits, and a project still provisioning

What is here today

Passwordless sign-up by emailed code, optional passwords, social login with Google and GitHub, passkeys, two-factor by TOTP, organizations with roles and invitations, enterprise SSO by OIDC and SAML, SCIM directory sync, sessions, JWT issuance with JWKS, user management, and transactional email.

The build order is complete. What comes next is driven by what customers ask for.