Auth schemas
Auth schemas give your site's visitors their own accounts — registration, login, email verification, password reset — without you building any of it. These are end users: your customers, stored in your own database, entirely separate from the teammates who use the dashboard.
Creating one
Under Auth schemas, create a schema with:
- Name — a slug like
customers; it names the user collection (auth_data_customers) and the public URL path. - Application URL — the site these users belong to, e.g.
https://shop.example.com. This is also the only origin allowed to call the auth API from a browser — CORS is locked to it, not open. - Fields — at minimum an
emailand apasswordfield; add whatever profile fields you need (name, phone, preferences…). Field rules work as in schemas; passwords are stored as bcrypt hashes and are never returned by any API. - Require email verification — when on, accounts must verify before they can sign in; verification emails go through your mail integration.
The public API your site calls
All routes live under /api/projects/{project}/auth/{schema-name}/… and are called directly from your site (browser or server):
| Route | Does |
|---|---|
POST …/register | Creates the account (validated like any record), sends the verification email if required, returns the user and a token |
POST …/login | Email + password → { user, token }; blocked with EMAIL_NOT_VERIFIED until verification when required |
GET …/me | The signed-in user, from a Authorization: Bearer <token> header |
POST …/verify-email | Consumes the emailed verification token |
POST …/resend-verification | Sends a fresh verification email |
POST …/forgot-password | Sends a reset email (always answers success — it never reveals whether an email exists) |
POST …/reset-password | Consumes the emailed reset token, sets the new password |
POST …/change-password | Signed-in password change (current password required) |
POST …/logout | Ends the session client-side |
A minimal login on your site:
const { token, user } = await fetch(
`${API}/auth/customers/login`,
{ method: 'POST', headers: { 'content-type': 'application/json' },
body: JSON.stringify({ email, password }) },
).then(r => r.json());
localStorage.setItem('token', token);Tokens
Login returns a JWT valid for 7 days, cryptographically bound to this project, this schema and this workspace — a token from anywhere else fails verification. Send it as Authorization: Bearer <token>. There is no server -side session to expire; logging out is discarding the token.
Users in the dashboard
The schema's Users tab lists accounts, shows verification state, and lets your team correct or remove an account. Emails the flow sends (verification, reset) are logged with the rest of your email activity.
Where it gets powerful: personal endpoints
A custom endpoint can require a signed-in end user (auth mode logged-in end user). The flow then sees the caller as {{user.*}} — user.id, user.email, and your profile fields, with password and token fields stripped — so a query step filtered by customerId={{user.id}} returns only the caller's own records. That's "my orders" without a line of server code.