Widget notifications and delivery
A message being saved, a notification being accepted, and a customer reading a message are different events. Test and report them separately.
Two separate customer choices
| Choice | Where the visitor controls it | What it permits |
|---|---|---|
| Browser notifications | Notification bell and browser/device settings | Registering a supported device for new-message notifications |
| Marketing updates | Help → Receive updates and offers from this business | Receiving campaigns for that particular widget |
Installing a PWA, entering a phone number, migrating from WhatsApp, or joining a WhatsApp audience does not grant either permission automatically. Turning off marketing does not itself turn off support notifications.
Enable and test notifications
- Open the business's published HTTPS chat site in a supported browser. Use the installed PWA if that is how the customer will return.
- Start or resume a conversation, then select the notification bell and approve the browser prompt.
- If permission was previously denied, review the site's browser and device notification settings. A website cannot silently override a denial.
- Background the chat and arrange a new reply to that same visitor conversation.
- Confirm a notification appears, opens the correct chat, and does not expose another visitor's history.
The standard push message uses private, generic wording rather than putting conversation contents on the lock screen. Browser/device support, notification settings, subscription validity, network access and delivery workers affect availability. Background delivery is not guaranteed merely because installation succeeded.
What a new message triggers
The normal chat-message event can queue a Web Push notification for an active widget's eligible device subscriptions. A database insert alone, a silent event, or an event for a different conversation does not establish that a push was sent. Developers should use the supported messaging path rather than writing message records directly.
Campaign messages can remain available in chat even without a push subscription. Campaign eligibility still requires the separate marketing opt-in. See Broadcasts.
Interpret the result
| Signal | What it establishes |
|---|---|
| Message visible in chat / campaign sent | The message was stored for that visitor; not proof of device notification delivery |
| Web Push accepted | A push provider accepted at least one notification; not proof that the customer saw it |
| No subscription or expired | No usable subscription was available for that attempt |
| Suppressed or failed | Notification delivery did not proceed or encountered an error; inspect message and push results separately |
| Notification clicked / chat opened | An interaction was recorded; not proof that every message was read |
Campaign reporting can show these separate outcomes. Do not assume every ordinary support message exposes all campaign analytics.
Troubleshooting
- Message saved, no alert: check permission, the current browser identity, subscription, OS notification controls and whether the event was silent.
- Stopped after changing browser or phone: the new browser/device needs its own subscription. A matching phone number does not transfer private history or permissions.
- Site works, installed app does not: test from the installed app itself and report the browser, OS, app URL and approximate time.
- No one receives alerts: ask your administrator to check Web Push credentials and delivery workers. Do not share tokens or subscription endpoints in a public support request.
Native mobile apps are different
PWA Web Push does not automatically provide push delivery inside SDK-hosted Android or iOS apps. Native background notifications require the host application's platform push integration, permissions, device registration and authenticated deep-link handling. See Embed Mobile Chat.
See also Mobile access, Chat Widgets and Companies and branding.