> ## Documentation Index
> Fetch the complete documentation index at: https://notifizz.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Multi-Channel Notification Platform

> Notifizz delivery channels — Notification Center widget today, email next. One campaign, one or more channels, no SDK changes.

# Channels

A channel is a delivery method for a notification. A campaign picks one or more channels; the SDK call site never references them. Each channel has its own configuration and its own template — but the same orchestrator output drives all channels of a single campaign.

## TL;DR

* **Notification Center** — in-app widget, real-time via real-time stream. Available today.
* **Email** — transactional + marketing email, written into the codebase, scheduled to ship next.
* **Channel choice is per campaign**, not per call. Adding email to an existing campaign is a dashboard change.

## Notification Center (in-app)

The Notification Center is the in-app widget channel — a bell icon with an unread badge and a dropdown list of notifications. It's available through three SDKs that wrap the same widget:

<CardGroup cols={3}>
  <Card title="React" icon="react" href="/docs/sdks/notification-center/react">
    `NotifizzInbox` component.
  </Card>

  <Card title="Angular" icon="angular" href="/docs/sdks/notification-center/angular">
    `<notifizz-bell>` standalone component.
  </Card>

  <Card title="Vanilla JS" icon="js" href="/docs/sdks/notification-center/vanilla-js">
    `createNotifizz()` API.
  </Card>
</CardGroup>

### What it provides

* **Default UI** — bell + dropdown out of the box, zero styling required.
* **Custom bell** — replace the default with your own component while Notifizz manages data and state.
* **Headless mode** — skip the bell entirely, build a fully bespoke notification UI from the SDK's state stream.
* **Real-time delivery** — new messages appear the moment they're written.

<Note>
  Real-time delivery for the widget uses the **real-time stream** listener — the widget subscribes to the user's notification document, the backend delivers new messages to the inbox. The dashboard activity log uses SSE for a different concern — don't confuse the two.
</Note>

### State model

All NC SDKs expose the same `NotifizzState` object:

| Property      | Type       | Description                                  |
| ------------- | ---------- | -------------------------------------------- |
| `isReady`     | `boolean`  | Widget loaded and authenticated.             |
| `isOpen`      | `boolean`  | Dropdown is open.                            |
| `unreadCount` | `number`   | Current unread count.                        |
| `lastUpdated` | `number`   | Timestamp (ms) of the last state change.     |
| `hasError`    | `boolean?` | `true` if an auth or network error occurred. |
| `errorCode`   | `string?`  | Error identifier when `hasError` is `true`.  |

Subscribe to changes (e.g. update the page title with the unread count) — see [Notification Center overview](/docs/sdks/notification-center/overview).

## Email

Email is the next channel. Notifizz models it the same way as the Notification Center: a campaign step picks an email `notificationConfig` (a stored email template), the orchestrator builds the recipient list, the email channel processor renders the template and dispatches.

### Customer-facing setup

* **Sender identity** — verify a sending domain (DKIM / SPF / DMARC); configure the From address in the dashboard.
* **Template editor** — the same dashboard editor that powers NC templates, with email-specific blocks (subject, preheader, …).
* **Tracking** — open / click events report back via Postmark inbound webhooks and feed the campaign's stats funnel.

<Note>
  Email is wired in the codebase but the queue dispatch path is not flipped on yet. The docs describe the customer-facing surface as it will ship. Track the docs gap audit for status.
</Note>

### One campaign, multiple channels

A single campaign can pick more than one `notificationConfig` step — for example, an in-app NC message **and** an email. The orchestrator resolves recipients once; each channel processor renders its own template against the same recipient list. There is no duplicate orchestration, no double counting in stats.

## Future channels

Push notifications and SMS are on the roadmap. The shape stays the same: a campaign step picks a `notificationConfig` whose `channelType` determines the dispatcher. Adding a new channel to an existing campaign will be a dashboard change.

## FAQ

<AccordionGroup>
  <Accordion title="Can I send the same campaign to NC and email at the same time?">
    Yes — once email ships. Add an email step to the campaign alongside the NC step. The orchestrator resolves recipients once; both channels deliver to that list with their own templates.
  </Accordion>

  <Accordion title="My email template renders fine in preview but never lands in inboxes.">
    Most likely the email queue dispatch hasn't shipped yet (see the Note above). Until then, treat email-channel campaigns as Editing. Once dispatch flips on, deliverability problems usually trace to the sending domain not having DKIM/SPF set up — verify in the dashboard.
  </Accordion>

  <Accordion title="Can I bring my own email provider (SendGrid, Postmark, …)?">
    Not at launch. The built-in dispatcher uses Notifizz's provider so deliverability is handled for you. BYO-provider is on the longer-term roadmap.
  </Accordion>

  <Accordion title="Where do open / click events show up?">
    On each delivery's stats funnel and on the campaign's aggregated metrics. The widget reports NC `read` / `opened` / `clicked` directly via `POST /v1/notification/event/register`; email reports the same shape via inbound webhooks. See [delivery history & stats](/docs/operations/delivery-history-and-stats).
  </Accordion>

  <Accordion title="Why isn't `client.send(...)` an option anymore?">
    `client.send()` and the direct NC track route were removed — they let the call site bypass the orchestrator entirely, which contradicts the event-driven model. Channels are a campaign decision now, not a call-site one.
  </Accordion>

  <Accordion title="What's the latency from `track()` to the bell badge updating?">
    Acceptance is millisecond-fast. End-to-end depends on orchestrator complexity. Simple campaigns (no enricher) deliver in under a second; campaigns with cold enrichers can take a few seconds. The widget receives the inbox write the moment it commits.
  </Accordion>
</AccordionGroup>

## See also

<CardGroup cols={2}>
  <Card title="Notification Center overview" icon="bell" href="/docs/sdks/notification-center/overview">
    Lifecycle, state model, custom bell, headless mode.
  </Card>

  <Card title="How Notifizz works" icon="diagram-project" href="/docs/concepts/how-it-works">
    The event-driven pipeline, end to end.
  </Card>

  <Card title="Frontend quickstart" icon="browser" href="/docs/quickstart/frontend">
    Render the NC widget in five minutes.
  </Card>

  <Card title="Authentication" icon="key" href="/docs/concepts/authentication">
    How users authenticate to the widget.
  </Card>
</CardGroup>