Notification Preferences

Channel matrix (in-app, email, web push, APNs) and per-category preference management.

Rensei can reach you on four channels: in-app, email, web push, and mobile push (APNs, via the iOS app). Which events use which channels is controlled from a single preference center, shared by web and iOS.

Where to manage preferences

Preference matrix - /{orgSlug}/settings/notifications. A grid of notification categories against channels: turn any category on or off per channel, independently.
Notification list - /{orgSlug}/notifications. Every notification you've received, not just the unread bell popover.
iOS - the app's notification settings screen renders the same category list live from your preferences - it is not a separate, hardcoded list that can drift from the web one.

Enabling browser push asks for the browser permission only when you click the enable button on the preference page - never on page load.

How a preference resolves

Categories have a sensible default (which channels are on) baked into the platform. You only need to set an explicit preference for a category if you want something different from the default:

If you have an org-specific preference for a category, that wins.
Otherwise, if you have a preference set for that category at all, that wins.
Otherwise, the category's built-in default applies.

This means an empty preferences table is not "no notifications" - it's "the defaults for every category." Turning things off is opt-out, not opt-in.

Channels

Always available. Appears in the notification bell and the notification list. Not user-configurable off - it's the baseline record of what happened.

Sent via Resend from notifications.rensei.ai. Delivery is deferred (queued after the request that triggered it completes), so an email lands a short time after the in-app notification, not necessarily instantly.

VAPID web push to your browser. Requires the one-time browser permission grant from the preference page. A test-send button on that page lets you confirm delivery without waiting for a real event.

Delivered to the iOS app via Apple Push Notification service (HTTP/2). Registering a device happens the first time the app asks and you grant permission - not automatically at first launch. See iOS App for the device-registration flow.

Interactive session notifications

The two events you'll see most often if you use interactive sessions:

Duration warning - fires when a running session approaches its plan's duration limit (see Quotas & Plans), so you have time to save work or extend before it's stopped.
Session ended - fires when a session stops, for any reason (normal exit, quota stop, manual stop, admin force-stop).

Presence changes (someone else joining as a viewer, or taking the pen) are deliberately not pushed as notifications - they show up live in the presence strip while you're attached, but don't generate a push, email, or bell entry. A busy session with several viewers coming and going would otherwise be noisy.

Device tokens

The iOS app (and, for web push, your browser) registers a device token with POST /api/notifications/devices. Tokens are scoped to the user that registered them - device tokens are never visible to other users or org admins, since they carry the raw push credential. Uninstalling the app or revoking a browser's permission removes the corresponding token; stale tokens are also cleaned up automatically after a period of inactivity.

Quiet hours are not currently available - there is no schedule or digest-cadence setting that batches or delays notifications to a time window. A category's "digest" toggle, where present, is an opt-in flag rather than a batching schedule; it does not yet aggregate multiple events into one send.

Interactive Sessions - the sessions these notifications are about
iOS App - device registration and Live Activities
Quotas & Plans - what triggers a duration warning