Read and filter the notifications feed
The notifications page (/notifications, reached from the bell in the top bar) renders your org’s in-app alerts as a virtualised list. Each row is a category icon, a title and body, a relative timestamp, and a severity badge — and rows with an action link open straight into the surface that resolves them (security alerts to your security settings, wallet alerts to billing, delivery alerts to the email module). This page is the operations counterpart to Triage the Notification Center, which covers delivery channels, digests, retention, and the API.
Above the feed, the page also pins Active platform alerts — persistent cross-module issue states (outbound paused, KYC pending, compliance risk, webhook backlog, number document expiry) — so the center is never empty while a real issue is outstanding.
Category taxonomy
Every notification has a kind — a closed enum that the page’s filter dropdown mirrors exactly, so a kind can never be invisible to filtering. Each kind renders with a dedicated icon; kinds without a mapping fall back to the severity glyph (info circle, warning triangle, or error octagon), and ultimately to a generic bell, so newly added kinds always render something recognisable.Platform events
Security alerts
Security kinds are always shown regardless of your notification preferences — suppressible preferences would let a hijacked session mute the takeover signal.
Agent and inbox activity
On rows, severity is tinted across the icon and badge: blue for info, amber for warning, red for error. Rows with warning or error severity also carry an explicit severity pill next to the timestamp.
Filters and read state
Three filters combine freely in the Filters card; a Clear control appears whenever any filter is active:- Unread only — toggle that narrows the feed to unread rows.
- Kind — dropdown mirroring the full kind enum. The list is group-ordered (security kinds cluster together, inbox kinds cluster together) rather than alphabetised, matching how you think about what you’re filtering for.
- Severity —
info,warning, orerror.
Read, dismiss, retention
- Mark read — hover a row to reveal its check button, or open the row (opening marks it read). Mark all read in the header clears the badge in one click.
- Dismiss — hover a user-scoped row to reveal the dismiss control; the row hides immediately and the delete commits after a short undo window (~5s). Org-wide rows show no dismiss control — they expire on their own clock.
- Retention — rows carrying an expiry timestamp drop out of every list and unread count once it passes; rows without one persist until dismissed.
Live updates
The page subscribes to the notification live stream, so a new row lands without a refresh and read state stays in sync across open browser tabs. If the live channel hiccups, the unread-count badge self-corrects on its next poll, so the badge can never get stuck on a stale number. Security-critical kinds (sign-in from a new IP or device, 2FA changes, password or email change, API key mint/revoke, member-role changes, billing anomalies) always mint a row and always bypass per-category mutes — a hijacked session can’t silence the takeover signal.Choosing the right channel
Notifications are for a human operator; webhooks are for your code. A notification is a durable UI row an operator triages from the dashboard — no endpoint to expose. A webhook is a server-to-server POST to an endpoint you control, processed automatically. Developer-facing failure modes (dead-letter queue, endpoint auto-disabled, decryption failures) mint both, so an operator sees the failure even when your webhook handler isn’t watching. For the full webhook event catalog, see Webhook events. Outbound push notifications to your end users — the push APIs (/push/categories, /push/scheduled, /push/telemetry) — are covered in the push integration guide and push notification categories. For programmatic access to the in-app feed itself (list, unread count, mark-read, dismiss, SSE stream), see Notifications API.