Skip to content
Platform · Messaging & Delivery

Six channels. One send. One delivery record.

Transactional traffic, campaigns and journeys converge on one routing layer and one audit trail. You decide the order; the carrier's own signals decide when to move on.

THE PRINCIPLE

The carrier says when to move on, not a timer.

A fallback that fires on a clock sends twice to people who already got it. A fallback that fires on a carrier failure sends once, on the channel that can reach them.

Everything on this page follows from that: routes you own, lanes that don't compete, content built per channel, and a record that shows every attempt as the carrier reported it.

01 · Send by intent

Send a template, or send the text you already have

Send a template with variables, or send finished text from your core system and let the platform recognise, categorise and group it. Nothing gets rewritten on your side. Duplicate requests inside a window are refused. Blocked content is refused. Every call is authenticated with your API key, and can be restricted to your own IP addresses.

  • Raw text recognised as OTP, alert or statement
  • Duplicates inside a window refused
  • Blocked content refused before it reaches a carrier
02 · Routing

Routing you change on save, not in a ticket

Smart Routing picks the channel and the order from availability and reachability. Custom Routing follows your order, per message type, effective the moment you save. When a carrier degrades mid-campaign, you reorder it and the next message routes differently.

  • Smart: availability and reachability decide
  • Custom: your order, per message type
  • Effective on save, mid-campaign included
03 · Fallback

Fallback on real signals

The chain advances when the carrier reports a failure, not when a timer expires. Each step sends the content built for that channel. Every attempt is recorded against the message.

  • Advances on a carrier failure signal, not a timer
  • Channel-specific content at every step
  • Each attempt on the record
04 · Lanes

A promotion does not queue in front of a login

OTP, transactional, marketing and informational traffic each get their own route, escalation and dispatch rate, on your own provider accounts. A promotional burst does not compete for the throughput a login depends on, on the platform side.

  • Four lanes, four routes, four rates
  • Your provider accounts, your contracts
  • Bulk sends stop mid-run if they're wrong
05 · Content per channel

One message, built for every channel

A template carries a variant per channel, each edited in its own tab with a live preview and its limits enforced as you type. If a template's category changes on Meta's side, the change is received from Meta's notification or found at the next template synchronisation: WhatsApp is removed from that template's channels and the change is logged, so new sends no longer go out on WhatsApp through it. Messages already submitted before the change was received may still incur charges. Other channels continue, and you decide whether to restore it.

Hi {first_name}, your card ending {last4} is ready. Activate in the app: {short_link}
PLAIN TEXT · SENDER ID96 / 160
06 · The record

Prove what happened.

Every message keeps its route, each attempt, the carrier status and the outcome, queryable and exportable. Delivery events post to your systems as they happen, so you keep your own record.

  • Route, attempts, carrier status, outcome, per message
  • Queryable in the portal, exportable in bulk
  • Webhooks to your systems as each event lands
Delivery webhooks · Your systems stay current

Your systems hear about every delivery the moment it happens.

Every change in a message's state is posted to an endpoint you register, as it happens: accepted, sent, delivered, read, failed and why, and each fallback attempt in between. Your CRM, your core system or your support desk keeps its own record of what reached the customer, with no polling and no waiting for a report. Replies and journey events arrive the same way, on the same connection.

What each status means
Accepted
The platform validated the request and queued the message.
Sent
Handed to the carrier or provider for the channel attempted.
Delivered
The carrier or provider confirmed delivery to the handset, app or mailbox.
Read
The recipient opened it. Reported on WhatsApp, Push and Inbox; email reports an open where the client allows it; SMS has no read state.
Responded
A reply, button tap, keypad press or click came back as an event.
Failed
The carrier or provider reported a failure, with the reason. This is the signal fallback advances on.
What comes back, per channel (and for Smart Links)
SMSDelivery status and inbound replies
WhatsAppDelivery, read receipts and button taps
PushDelivery, opens and clicks
InboxDelivery, read state and button clicks
EmailDelivery, opens and clicks
VoiceCall outcome and keypad responses
Smart LinksClicks and referral attribution
Next step

See what xNotify could do for your customer journeys.

After the demo: how the pilot works
Book a Demo