Skip to main content

​
Channels (detailed)

This page extends the channels concept with per-channel setup and dispatch details. For the high-level mental model, start there; this page is the practical setup reference.

​
TL;DR

  • A campaign step picks a notificationConfig whose channelType decides the dispatcher (notificationcenter, push, or email).
  • The orchestrator builds the recipient list once; per channel, the system iterates and dispatches.
  • Notification Center is the in-app widget channel — real-time delivery.
  • Web push reaches the device with the tab closed — one environment key, one static service worker file.
  • Email: sender-domain authentication from the dashboard, open/click tracking with nothing to wire, same campaign editor.

​
The dispatch model

Every campaign step references a notificationConfig. Each config has a channelType: The orchestrator returns one recipient list per workflow instance. The dispatcher iterates that list per channel — same recipient receives the message on every channel the campaign configures.

​
Notification Center

In-app widget channel — new messages appear the moment they’re written. Three frontend SDKs (React / Angular / Vanilla) wrap the same widget — see Notification Center overview for the SDK surface.

​
Setup

  1. Create an NC config in the dashboard — the template (subject + body + variables) for this notification.
  2. Reference it from a campaign step — the dashboard editor lets you pick the config from the org’s library.
  3. No additional infrastructure — the widget script + your Front API Key + the right authType is all the frontend needs.

​
Real-time mechanism

The widget opens a real-time stream scoped to the signed-in user. New messages are delivered to the inbox and pushed onto that stream; the widget renders the new entry in the dropdown and updates the unread badge. Reconnection and offline catch-up are handled by the platform — your code never deals with reconnection logic or polling. The dashboard’s activity log uses a separate streaming channel for collaborative team feeds; don’t conflate the two.

​
Read / opened / clicked tracking

The widget reports back to the backend: Each event is keyed by (messageId, eventType) — duplicates dedupe. See delivery history & stats for the funnel visualisation.

​
Web push

Browser push channel. A campaign step picks a web push notificationConfig (title, body, icon, click URL); at dispatch, Notifizz encrypts the payload and sends one push per active subscription of the recipient. A user can have several — one per browser and device — and each settles independently; subscriptions the browser has revoked are pruned automatically.

​
Web push setup

1

Generate the environment key

Settings → Web push creates a VAPID key pair for the environment. The public key is served to your frontend automatically; the private key never leaves the Notifizz backend.
2

Serve the service worker

Download notifizz-sw.js from the same page and serve it at the root of your application’s origin. It registers under a dedicated scope, so it never conflicts with your own service worker or PWA.
3

Collect the opt-in

The Notification Center widget shows a dismissible soft prompt once the environment is configured — or drive the opt-in from your own button with the SDK. The native browser dialog only fires on the user’s click.
4

Create a web push config and reference it from a campaign step

Same dashboard editor. Title and body budgets differ per platform — see platforms & privacy.

​
Email

Transactional and marketing email. A campaign step picks an email notificationConfig; the template is rendered per recipient, tracking and the unsubscribe block are injected, and the message goes out on the stream matching its kind — transactional and promotional travel separately so one cannot spoil the other’s reputation.

​
Customer-facing setup

1

Authenticate a sending domain

Add your domain in Settings → Email → Domains. Notifizz generates the DKIM, return-path and (recommended) DMARC records; add them at your DNS provider, or let the dashboard publish them for you where your provider supports it. Verification happens on its own once the records propagate, and the records keep being re-checked afterwards.
2

Add the From addresses

Senders live on the verified domain — typically notifications@yourdomain.com, with its own display name. One sender is the default campaigns use.
3

Create an email config

Same dashboard editor as the NC config — subject, body, variables. The editor exposes email-specific fields (preheader text, plain-text fallback).
4

Reference from a campaign step

Add an email step alongside (or instead of) the NC step. The orchestrator builds the recipient list; the email dispatcher renders + sends per recipient.
Open / click / bounce / complaint events come back through the sending provider’s delivery webhooks — Notifizz owns that plumbing, there is nothing to configure on your side. Bounces and complaints are suppressed from future sends, and your domain’s reputation is tracked per mailbox provider in Settings → Email → Reputation.

​
Multi-channel campaigns

A single campaign can pick more than one channel step. Common patterns:
  • NC + email — in-app for active users + email as a fallback for offline users.
  • NC only for transactional — invoice paid (in-app receipt) + reserve email for marketing.
  • Email only — pure marketing campaigns where the user isn’t expected to be in-app.
The orchestrator runs once per matching event; channel dispatchers iterate the same recipient list. There’s no double counting — each (messageId, eventType) pair is unique per channel.

​
Why no client.send()

The pre-event-driven design exposed a client.send() method that wrote a Notification Center message directly. It was removed — channel decisions belong to the campaign, not the call site. The migration is straightforward — emit an event, let a campaign decide channel and recipients.

​
FAQ

Yes — add both as separate steps in the campaign editor. The orchestrator runs once; both channels dispatch to the same recipient list. Each channel has its own template; you can copy-paste between them and adjust per-channel formatting.
Two layers to check:
  1. Sender domain authenticated? Email delivery requires a verified DKIM + return-path on the sending domain. Unauthenticated domains fail at the provider level, visible in the dashboard delivery history with the bounce reason.
  2. Right send scope? A real send needs a Live campaign triggered from production. In Review, email only reaches your sandbox testers — see send scope.
Not at launch — Notifizz uses its built-in provider so deliverability is handled for you. BYO-provider is on the longer-term roadmap.
On each delivery’s stats funnel and on the campaign’s aggregated metrics. The widget reports NC events directly via POST /v1/notification/event/register; email reports the same shape via inbound webhooks. The funnel renders both side-by-side per channel.
The dispatch model accommodates it — a new channelType value plus a new dispatcher. That’s exactly how web push landed. SMS is on the roadmap; it will feel like NC, web push and email from the campaign-author side.
The dashboard editor exposes channel-specific fields (preheader for email, action buttons for NC). Variables and brands work the same across channels — see brands and variables.

​
See also

Channels overview

Higher-level mental model.

Notification Center overview

Widget SDK surface across React / Angular / Vanilla.

Brands and variables

Templating across channels.

Delivery history & stats

Per-channel funnel.

Web push

Environment key, service worker, opt-in.

Platforms & privacy

What each OS renders, and the encryption model.