Push on your own terms. Content that never leaves 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.
Elsewhere, push works by giving your message to Google or Apple to deliver. The content passes through, and is visible to, infrastructure neither you nor your vendor controls, and the vendor learns little beyond "accepted". 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.
Because the content never transits a third party, it stays inside the platform's infrastructure. Run xNotify as a dedicated, in-country or on-premise deployment and push content never leaves your jurisdiction, and neither does the device registry it depends on. This is the difference between push being available and push being approved, and it is not a setting a platform that hands the message over can offer, because handing it over is how that model works.
What the device makers see.
| Aspect | TYPICAL PUSH | 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, the vendor | 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" | 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 |
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 most platforms can only say "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. The content stays encrypted to a key only that device holds, so we can tell you a message was read without ever being able to read it ourselves. Evidence of engagement, with no access to the message.
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. People who installed and registered but never gave you a number are reachable here, and nowhere else.
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 ends at "accepted", and whose cloud decides where your customers' messages live.