Push on your own terms. Content that stays under your control.
xNotify runs its own push and in-app delivery network. The message travels over our connection to the device. The device-maker networks only wake the phone.
xNotifyMost push is a hand-off. Ours isn't.
In the usual model, push works by handing your message to the device-maker network to deliver. Unless the app encrypts the payload itself, the content passes through infrastructure neither you nor your vendor controls, and the vendor often learns little beyond "accepted" unless the app reports back. For a bank, a government body or anyone with confidentiality obligations, that is usually the reason push never gets approved. xNotify was built the other way round.
Built on our own infrastructure.
Your app keeps a live connection to xNotify's own servers, and the message content is delivered over that connection. The registry of devices is held on the platform, not with a third party. If a phone is asleep, the device-maker network is asked to wake it with a content-free signal, the phone reconnects, and it collects the message from us. That wake-up is the one thing we still rely on the device makers for, and it carries nothing but a nudge.
Data sovereignty, by design.
The content travels over the platform's own connection to the device, not through a third-party push network; the device-maker network receives only the content-free wake-up. Run xNotify as a dedicated, in-country or on-premise deployment and the message content and the device registry stay on that deployment's infrastructure. Support access, backups and any optional external-model inference are covered in the security white paper, so your reviewers can see the whole picture rather than one path.
What the device makers see.
| Aspect | PUSH BY HAND-OFF (AS COMMONLY CONFIGURED) | XNOTIFY PUSH |
|---|---|---|
| Who carries the message | The device-maker network | xNotify's own connection to the device |
| Who can see the content | The device-maker network and the vendor, unless the app encrypts the payload itself | The platform at composition; after that only the device, which holds the key |
| What the device maker receives | The full message | A content-free wake-up |
| What you learn back | "Accepted" by the network, unless the app reports more | Delivered, opened, clicked; read and tapped on Inbox |
| Where it can run | The vendor's cloud | Cloud, dedicated, in-country or on your own servers |
The left column describes the common configuration: the payload handed to the device-maker network in the clear, with no in-app read reporting. Apps that encrypt the payload themselves or report reads back differ; ask your vendor how yours is set up.
Encryption, stated exactly.
Each message is encrypted to a key generated inside the phone's secure key store. Only the public key reaches xNotify, so no server-side key can read a delivered message. This is device-targeted payload encryption, not end-to-end: the platform composes the message, so plaintext exists at composition. Hardware backing of the device key depends on the handset and configuration. Review the full model with your security team.
Measured, not inferred.
Because we carry the message, we know what happened to it. Delivery, opens and clicks on push. Delivery, read state and button clicks on Inbox. The same depth of feedback WhatsApp gives you, on channels where reporting often stops at "sent". All of it lands as events, so a journey can wait on a read or a tap rather than a timer.
Receipts without reading.
The read receipt and the click come back from the device as events. A delivered message stays encrypted to a key only that device holds, so the read can be reported without any server-side key that could decrypt what was delivered. The platform composes the message before it is encrypted, as the encryption section states, so this is evidence of engagement on a device-targeted model, not end-to-end secrecy.
Every notification, on the record.
Each push and Inbox message keeps a complete audit trail: the route taken, every attempt including any fallback to another channel, and the delivered, read and clicked states with the time of each, queryable and exportable. The same events are posted to your own systems as they happen, so your record of what reached the customer lives with you, not only with us. When compliance asks what happened to one notification, the answer exists.
Inbox: a message centre inside your app.
Rich content with the weight of a WhatsApp message: media, formatted text and buttons, where customers return to what you've sent. Read state comes back per message.
An audience you need no phone number for.
An app subscriber is a first-class audience, addressed by their app identity. Reach app users without requiring a phone number.
In a journey.
Push and Inbox are ordinary send steps, with fallback to another channel if a device stays unreachable. Two listening steps are built for them: wait for the message to be read, and wait for a button to be tapped, each with a deadline and a path for silence.
Into your app in an afternoon.
SDKs for Android, iOS, Flutter and React Native handle registration, receipt and Inbox rendering. Your mobile team wires up push and Inbox on their own, without taking events or Stories at the same time.
A push vendor you rent, whose network carries your message, whose report often ends at "accepted", and whose cloud decides where your customers' messages live.