Site visitors & members
A published site can have its own members — visitors who log in to see protected pages, submit forms, or shop. The platform builds this layer into every site.
Enable visitor logins
- Open your site and click Auth (or find the visitor settings under the site detail page).
- Toggle Login on.
- Choose one or more login methods — email, username, or Google.
- Save.
Your AI assistant can configure this too.
Google Sign-In requires the platform Google client (Admin → Settings → Google Sign-In) and adds a "Sign in with Google" flow for visitors. Clicking it starts
/auth/google/starton your site; the visitor returns signed in with the same session cookie as the other methods. Google accounts are linked per site only, and a brand-new account is created only when Google is also allowed as a registration method.
Self-registration
If you want visitors to sign up on their own:
- In the Auth settings, find Registration.
- Set it to enabled and choose a mode:
- Open — new accounts are active immediately and logged in.
- Approval — new accounts are pending until an admin activates them.
- Choose allowed registration methods and a default role.
- Save.
Self-registration can never grant the admin role — the first site admin is
always created by you (the site owner) from the dashboard.
Manage end users
Open your site and click Users to see every visitor account:
| Action | What it does |
|---|---|
| Create user | Add a visitor with a specific role |
| Edit user | Change their role or details |
| Toggle active | Enable or disable their login (disabled users are logged out immediately) |
| Export CSV | Download the user list as a spreadsheet |
| Delete user | Remove the account entirely |
Roles
| Role | Who they are |
|---|---|
| visitor | A logged-in visitor (default) |
| member | A visitor with member access — can view members-only pages and collections. Optionally time-limited (see below) |
| admin | A site end-user who can manage other members from the published site |
A site admin (an end user, not a platform user) can activate/deactivate
members and change roles directly from the published site — you build that admin
experience on a code page if you want it.
Members-only access (paywall)
Set a page's access to Members or a collection's read tier to member to require an active member account:
- A visitor (role
visitor) or an anonymous user is turned away. - A member sees the content.
- A site admin always sees it.
- If you give a member an entitlement expiry (Edit user → "Entitlement expiry"), they lose access automatically once it passes. Leave it blank for permanent access.
You manage expiry by hand on the Users list, or your AI assistant can set it
when it updates a user (the expires_at field). A payment product configured to
grant the member role on payment can also grant a fixed number of days
(access_days) — see the site payments guide.
To run a scheduled downgrade of expired members, point any external scheduler at
your site's signed task endpoint (expire_entitlements) — see your site's
Scheduled tasks card on the site edit page for the endpoint, secret, and an
example request.
Page access levels
Each page has an Access setting:
| Level | Who can view the page |
|---|---|
| public | Anyone |
| authenticated | Any logged-in visitor of the site |
| member | Logged-in members with an active entitlement |
| admin | Only site admins |
Access is enforced on every render — both subdomain and custom domain. Anonymous visitors on a restricted page see a themed login prompt instead of the content.
Per-user collections (each visitor sees only their own data)
Collections can use the Owner tier so every visitor reads and writes only their own rows (e.g. a profile, scores, or a form draft). Enable One row per visitor to make submissions update the visitor's existing row instead of creating a new one. A site admin can still see and correct any row.
Note: each row still counts toward your plan's total-entries limit, so a large class of users each writing one row uses many entries.