Notifications

A developer, admin, or owner composes one notification for the app’s active environment and sends it now, saves a draft, or schedules it. A viewer can open the list and the detail. A public key cannot send. A server API key can send, or read one notification, for the environment that key was created in.

How it works

The composer is its own page at notifications/new, opened from New notification. Send test, Save draft, and Send sit at the top of the page. Send test appears only while the app is in development. Send opens a dialog that asks when: now, at a UTC time, or at each subscriber’s local time, with the time when scheduled. After a send, draft, or schedule, it returns to the list. It asks for a title, a message, an optional tap path that suggests the deep links stored for this app, an optional image (uploaded, PNG, JPG, or GIF up to 1 MB, or a link), and whether the notification shows an alert. A lock-screen preview follows the app’s platform: an iPhone lock screen for iOS, an Android lock screen for Android, and tabs to switch between both when the app targets both. The iPhone shows the padlock, the date above a centered clock, and the notification near the bottom above the flashlight and camera. As on iOS, its notification shows the app icon, the title, and the message, and an image is a thumbnail on the right. The Android notification also shows the app name. An image appears on the lock screen only when an image URL is set. A silent notification carries data and does not show an alert. The audience is all users, one current segment, one event name, or one subscriber for a test. An event audience is every subscriber in this environment who recorded that name at least once, including notification_opened and notification_clicked. The segment list’s Send notification opens this composer with that segment selected. When the notification has a URL, each delivery’s link appends that delivery’s id as ?opt= or &opt= when the URL already has a query.

The audience menu shows how many subscribers are registered and how many are accepting, for all users, each segment, and each event name. One subscriber stays a person picker. Accepting means the subscriber can receive: active, permission granted, notifications on, a token, a provider, and not marked invalid. After a choice, the page says how many are registered and how many are accepting. When some are not accepting, that line is a warning with Request permission. Confirming it asks the people in that audience who denied notifications or have not been asked. It does not send a notification. People who already allowed notifications are left as they are. When every registered subscriber is accepting, the line is green. When nobody is registered, the line stays quiet. Delivery is queued only for subscribers who are accepting.

Accept freezes the audience. A later edit to the segment does not change a notification that was already accepted. Send now starts delivery. A fixed time stays scheduled until that UTC moment, then a command claims it. A subscriber-local time starts immediately and delivers each subscriber when that clock time arrives in their timezone. A missing timezone uses UTC. A local time that has already passed is sent on that run. Cancel is allowed only while the notification is a draft or still scheduled. The same accept rules apply when a backend sends with a server API key. That key’s environment is used, not the environment selected in the dashboard.

Delivery walks subscribers in small groups and records one outcome per subscriber. A retry does not send a subscriber who was already delivered. A dead token marks that subscriber invalid. A delivery without a usable Apple connection, bundle ID, prepared Android app, or Web Push key records those attempts as failed. A provider that does not accept a subscriber is tried again. When those tries are used up, that subscriber is recorded as failed with provider_rejected and does not stay pending. The notification is Sent when at least one subscriber was delivered. It is Failed when delivery has finished and nobody was delivered. It stays Sending while a delivery is still pending. A secret already stored on the app is used first. Expo can send without a stored credential. The list uses the same table as segments and subscribers: search, a status filter, and pages. Each row shows a status, the audience, delivered, failed, and the open rate. The open rate is unique opens against delivered. It stays blank until at least one subscriber was delivered. An empty list shows a panel with New notification instead of the table. A search or status filter that matches nothing stays in the table. Opening a row leaves the list and opens that notification. The page shows the title, status, message, audience, and when it was sent or scheduled, then the stored counts: targeted, delivered, failed, and skipped. The open rate is unique opens against delivered, and stays blank until at least one subscriber was delivered. Below that is this campaign’s delivery rows, newest first, in pages. Each row is the subscriber, their device and platform, whether they opened it, the outcome, the error code when there is one, and the time. The push provider is not shown. Search matches the subscriber name, email, or external id. A status filter limits the table to one outcome. A draft, a scheduled send, or a send that has no rows yet shows an empty table. Send and Cancel stay on that page while the notification is a draft or still scheduled.

Each real provider attempt counts toward the workspace notification limit. A skip, and a delivery that never reached a provider because credentials were missing, do not count. The overview uses the stored notifications for this environment: active subscribers, delivered and failed for the chosen range, a delivered series, and recent sends.