Loading…
/settings is the self-service preferences area — every signed-in user gets
it, so unlike the admin modules there is no requirePermission gate and
no layout.tsx guard. The page renders client-page.tsx, a tabbed shell
driven by the ?view= search param; a legacy ?view=profile value (and a
missing value) is normalised to ?view=security via router.replace.
| Route | Purpose | Guard |
|---|---|---|
/settings?view=security | Password-adjacent account security + 2FA enrolment (default tab) | Signed-in user only |
/settings?view=appearance | Theme variant picker | Signed-in user only |
/settings?view=preferences | Workspace personal preferences | Signed-in user only |
/settings?view=email-design | Transactional-email variant design + live preview | Signed-in user only |
Each tab is a component in components/: SecuritySettings.tsx,
AppearanceSettings.tsx, PreferenceSettings.tsx, EmailDesignSettings.tsx.
| Method | Path | Guard | Purpose |
|---|---|---|---|
GET | /api/auth/2fa/status | Clerk session | Read current 2FA state |
POST | /api/auth/2fa/setup | Clerk session | Start 2FA enrolment |
POST | /api/auth/2fa/enable | Clerk session | Confirm + enable 2FA |
POST | /api/auth/2fa/verify | Clerk session | Verify a 2FA challenge |
GET / PUT | /api/workspace/email-design | Workspace auth | Read / save email variants |
POST | /api/workspace/email-design/preview | Workspace auth | Render a variant preview |
The global site banner and downloads registry touched from Content tooling are
separate: GET /api/settings/banner and GET /api/settings/downloads are
WordPress-backed reads, while their writes require org:content:edit.