In-App Settings
The inventory#
Runtime-changeable configuration is stored in the framework database,
one table per concern — there is no generic key-value settings table.
Everything below is admin-only (the entire /settings area requires
the admin role) and every change is audited.
Global singletons (Settings tabs)#
| Surface | Settings tab | Encrypted fields | API |
|---|---|---|---|
| Notification settings | Settings → Notifications | SMTP password, license-alert target | /api/v1/notification-settings |
| Audit forwarder | Settings → Audit Forwarder | Forwarding target | /api/v1/audit-forwarder-settings |
| Backup settings | Settings → License & Backup | none | /api/v1/admin/backup-settings |
Provider collections (Settings tabs)#
| Surface | Settings tab | Encrypted fields | API |
|---|---|---|---|
| AI model providers | Settings → AI Models | API key (optional) | /api/v1/ai-providers |
| SSO providers (OIDC) | Settings → Authentication | Whole provider config blob | /api/v1/sso-providers |
| LDAP providers | Settings → Authentication | Whole bind config blob | /api/v1/ldap-providers |
Policy collections (Settings tabs)#
| Surface | Settings tab | Encrypted fields | API |
|---|---|---|---|
| Masking policies | Settings → Masking | none | /api/v1/masking-policies |
| Dataset retention policies | Settings → Retention | none | /api/v1/retention-policies — see Retention |
Per-resource configuration (outside Settings)#
| Surface | Where in the UI | Encrypted fields | API |
|---|---|---|---|
| Notification channels | /notifications page, attached to CDC tables, streams, and file ingestions |
Channel target | /api/v1/notification-configs |
| Alert rules | /alerts page |
Channel target | /api/v1/alert-rules |
Resource credentials follow the same encrypted pattern without being "settings": data-connector passwords, IMAP inbox passwords, and stream outbound auth headers are all stored as encrypted secret rows.
Note. All encrypted fields live in one
secretstable, wrapped with Fernet underABRQ_MASTER_KEY— see the configuration model for the key and rotation story.
Write-only secret semantics#
Secret-bearing fields are write-only through every API and UI surface:
- Reading back a saved secret is impossible. GET responses carry a masked preview (enough to recognize which credential is set — never the value).
- Setting or rotating uses an explicit flag-plus-value pattern: the update payload marks the secret field as "being set" and supplies the new value; omitting the flag leaves the stored secret untouched, so you can edit non-secret fields without re-entering credentials.
- Clearing is likewise explicit — a deliberate clear flag, not an empty string, removes a stored secret.
Decryption happens only at the moment of use (sending the email, posting the webhook, binding to LDAP) — never for display.
Settings tabs at a glance#
The Settings area (/settings, admin-only) has ten tabs: Users, API
Tokens, Audit Log, Authentication, AI Models, Notifications, Audit
Forwarder, Masking, Retention, and License & Backup. The tabs that hold
DB-stored configuration are covered above; Users, API Tokens, and
Audit Log are administration surfaces, and the license half of
License & Backup is read-only state — see
Licensing.