​

Web push

​

TL;DR

• Two setup steps. Generate the environment’s key in Settings → Web push, then serve one file — notifizz-sw.js — at the root of your application’s origin. The widget does the rest.
• Opt-in is the user’s. The Notification Center widget shows a discreet, dismissible prompt — or drive the opt-in from your own button with the SDK, no bell required. Either way, the native browser permission dialog only ever fires on the user’s explicit click.
• Same identity as the Notification Center. Recipients are matched on the user id your widget authenticates with — no separate audience to manage.
• Verified from the real browser. The widget checks in situ that the service worker is actually served on your origin and reports the result per environment — the settings page tells you exactly what’s wrong, with the fix.
• Privacy friendly. Payloads are encrypted end to end (RFC 8291); browser push services never see the content. Notifizz holds no customer data beyond the subscription itself.

​

How it works

1. Set up the environment. In Settings → Web push, generate the environment’s key pair. 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 — there’s a Download button right under this step in Settings → Web push — and serve it at the root of your application’s origin (https://your-app.com/notifizz-sw.js). It’s a static file: no build step, no code. It registers under a dedicated scope, so it never conflicts with your own service worker or PWA.
3. Let the widget do the rest. If you already run the Notification Center widget, web push is live: at load time the widget verifies the service worker, reports the setup state, and — once a user opts in — registers the browser’s push subscription with Notifizz.

<!-- Nothing new to install: the Notification Center widget carries web push. -->
<!-- Just make sure /notifizz-sw.js is served at your origin's root. -->

​

The opt-in experience

• A soft prompt appears at the top of the notification panel, only when the environment is configured and the user hasn’t decided yet.
• The native browser dialog fires only on the user’s click of the “Enable” button.
• “Later” dismisses the prompt and remembers the choice per browser.
• Opting out from the widget removes the subscription on both sides.

​

Opt-in from your own UI

import { useNotifizz } from "@notifizz/react";

// Anywhere inside your <NotifizzProvider>
function EnableNotifications() {
  const { webpush } = useNotifizz();

  if (webpush.status === "subscribed") {
    return <button onClick={webpush.optOut}>Turn off notifications</button>;
  }
  return (
    <button onClick={webpush.optIn} disabled={webpush.status !== "ready"}>
      Enable notifications
    </button>
  );
}

import { Component } from "@angular/core";
import { NotifizzService } from "@notifizz/angular";

@Component({
  selector: "enable-notifications",
  template: `
    <button
      (click)="notifizz.webpushOptIn()"
      [disabled]="(notifizz.webpushStatus$ | async) !== 'ready'"
    >
      Enable notifications
    </button>
  `,
})
export class EnableNotificationsComponent {
  constructor(public notifizz: NotifizzService) {}
}

import { createNotifizz } from "@notifizz/vanilla";

const notifizz = createNotifizz({
  apiKey,
  authType: "backendToken",
  userId,
  userEmail,
  token,
});
notifizz.mount();

button.addEventListener("click", () => notifizz.webpushOptIn());

// Keep the button in sync with the reactive status.
notifizz.onStateChange((s) => {
  button.disabled = s.webpushStatus !== "ready";
});

​

Sending

• Review never reaches real users. Before a campaign is Live, pushes are delivered only to your team’s sandbox testers — members who opted in from Settings → Web push (“Test on this browser”, capped at 5).
• Payload budget. Push services cap payloads around 4 KB; the composer keeps you within it, and titles/bodies are truncated aggressively by the OS (the composer’s platform preview shows exactly how).

​

FAQ