Keep the systems you rely on. Connect the customer experience.
Everything the portal does, your systems can do too, because the portal is a client of the same API. Five ways in, three ways out, and no connector catalogue you have to be on.
xNotifyONE API · PORTAL IS A CLIENTFive ways in, three ways out.
- INthe mobile and web SDKs, the event ingest API, the send API, the full REST API, and the tool surface for AI agents.
- OUTwebhooks to your endpoints, a journey step that calls your systems, and the answers those systems return into the journey.
One SDK per platform, four things it can do.
Kotlin for Android, Swift for iOS, Flutter and React Native, plus a web tracker for sites. Each covers four capability families, and your team can adopt any one of them on its own: wire up push this month and events next quarter, or the other way round. The portal carries per-platform integration documentation and configuration for each.
Sessions come for free. The web tracker and the mobile SDKs assign and carry the session themselves, so you get session journeys and session-triggered journeys without instrumenting anything for them.
| Icon | CAPABILITY | WHAT YOUR APP GETS |
|---|---|---|
| Push & Inbox | Device registration, push received over xNotify's own delivery network, and the in-app Inbox rendered inside your app | |
| Events | Behavioural event capture, user identification, and attribute updates, with anonymous activity stitched to the customer once they identify themselves | |
| Stories | Full-screen Stories rendered inside your app, published without a release | |
| Install attribution | Installs reported back so a click on a link can be matched to an install: deterministic on Android, an estimate on iOS |
For servers and everything without an SDK.
Send behavioural events from your backend, a data pipeline or a partner system. Standard ingest is queued, so a spike lengthens a queue rather than blocking your callers. A confirmed mode is there when a caller needs to know the event landed. Batch ingest handles bulk submission and replay.
Bring your history with you. A file-driven path backfills years of events from a previous system while live traffic keeps arriving through the queued path, and both land in the same store. Migration starts with your history, not from zero.
No schema to declare. Events carry whatever attributes you send; the platform derives the catalogue from what arrives and shows drift when it changes.
Point your systems at it as they are.
Three ways to send. A structured send: a template and its variables, composed and routed by the platform. A pass-through send: the finished text your core system, ERP or claims system already produces, recognised against your templates so it is categorised, grouped, priced and reported without you rewriting anything. A subscriber send: to an app user by their app identity, with no phone number needed.
You choose the routing per call. Let the platform pick the channel and the fallback order, follow your own configured order for that message type, or name one channel.
What the platform refuses. Malformed requests, duplicates inside a window you set, and content that trips your own blocklist, so a retry or a double-submit never becomes two messages to the same customer, and no caller can route around your content policy.
What you get back. A message id that is the handle for everything after: delivery state, the outbound webhook, the audit trail, every fallback attempt. The original request is kept with the message. A pricing lookup lets you check the cost of a destination before you send.
Access. Every call carries an API key that resolves to your account and nothing else, with a request limit per account at the edge. Where you require it, access can also be limited to the IP addresses you nominate.
What a person can do, a system can do.
Send, contacts, segments, campaigns, journeys, templates and reporting are all on the same API the portal itself uses. There is no privileged interface behind the screens. A journey can even be started by an API call from your own system, so a decision that lives in core banking or a fraud model can begin a journey it never has to see.
Three ways out
Webhooks to your endpoints.
Delivery events, replies and journey events are posted to endpoints you register, as they happen, so your helpdesk, your data warehouse or your core system keeps its own record of what reached the customer. Inbound replies and carrier callbacks arrive on the same listener.
A journey step that calls your systems.
Any system with a REST API can be consulted or updated mid-journey: check a balance before offering a top-up, read a risk score before releasing a confirmation, fetch open delivery slots, open a support ticket, write the outcome back. The step supports the four common authentication schemes, waits for the answer with a bounded timeout or fires and continues, and hands the answer to every later step by name. The rule stays in the system that owns it; the journey asks the question.
A tool surface for your AI agents.
Your own agents connect through an open standard to 112 actions, filtered to the scope you grant: build a segment, launch a campaign, run a journey, send a message, publish a Story. Writable, never destructive, with a rehearsal mode and a guarantee that a retry never repeats an action.
Methods, not a connector catalogue.
Most platforms in this category ship a fixed list of connectors, and a prospect's first question is whether their systems are on it. Here the integration is the SDK, the API or the journey step, built by your team in the same sitting, and a system the vendor has never heard of works on day one.
A typical path. Start with messaging: point an existing system at the send API with nothing else adopted. Add capture with an SDK or the ingest API. Build the first journey, and let it consult your systems where it needs to. Connect your agents last. Each step is independent, and none requires the one before it.
For the implementation team. Per-platform SDK documentation and configuration live in the portal. For a pilot, what is needed from you is a developer to place the SDK or call the ingest API; everything after event capture is portal work.