Subscribers

A subscriber is a user or guest device an app can reach with a push. The subscribers page lists the people and anonymous devices stored for the app’s active environment. A client SDK saves and updates those devices, including push permission, with the environment’s public key. A developer, admin, or owner can ask selected people to opt in again, or ask everyone who denied notifications. The next SDK save for each of those devices returns prompt_permission.

How it works

Opening subscribers shows one page of the app’s live subscribers for the environment that is currently active, newest activity first. The first page holds 10. The page size can be 10, 25, or 50. Search, platform, and push permission are applied in the database before that page is loaded. Search matches the subscriber id, email, name, external id, anonymous id, device id, device model, and push token. A search or filter with no matches keeps the table and shows no results. The table shows a skeleton while that request is in flight. When the workspace’s production subscribers reach the plan cap, the owner sees an upgrade card at the bottom of the sidebar. Development subscribers do not count and are not capped. Upgrade opens the plan picker. Development shows development subscribers. Production shows production subscribers. A person who is not a member of the workspace receives 404. A soft-deleted subscriber is hidden.

Each row is one device. The first column is a Subscribed or Unsubscribed badge. Then a platform (iOS, Android, or Web), a country, push permission (Push enabled, Push denied, or Not asked), tags, the device model as a badge followed by a masked device id, and when the device was last seen. In development, the subscriber icon uses the same amber glaze as the development mode badge. A named subscriber shows their name. A subscriber with no name and an anonymous id shows as Anonymous.

The detail panel lists the stored record in sections. In development, a Development badge sits beside the name. Identity starts open. Push token, device, location, status, attributes, and tags start collapsed. The push token and token hash are shown in full. An enable switch turns notifications on or off. Turning it off sets the subscriber to inactive. Turning it on sets the subscriber to active. A viewer can open the panel and cannot change the switch. A developer, admin, or owner can.

An app with no subscribers in the active environment shows an empty state in the same place and width as the table. It lists connecting the SDK, asking for notification permission, and opening the app once. How to capture subscribers in-app? opens the client snippet for the app. View documentation sits under that button. The public key in that snippet shows its first 8 characters until the eye reveals it, and copy still copies the full snippet. Subscribe, unsubscribe, request permission, and delete apply after a confirmation. When every selected subscriber is unsubscribed, the bulk action is Subscribe. Otherwise it is Unsubscribe. Subscribe turns notifications back on. Unsubscribe keeps the subscriber and stops notifications. With nothing selected, Request permission sits at the top and asks everyone in this environment who denied notifications. With people selected, Request permission appears in the selection bar for those who denied permission or have not been asked. Someone who already allowed notifications is left as they are. The next time that device is saved, the SDK can ask for permission again. Delete removes the subscriber from the app. A viewer can see the list and cannot run these actions.