Order confirmations
The confirmation is the message your customer keeps — forwarded, screenshotted, quoted back to support. Send it the moment the order lands, on a channel they actually read, and let the log answer for it later.
Read more →SMS, without moving your provider
SMS is the channel this platform was built around, and the one that carries the fullest set of channel-level capabilities. Email and WhatsApp connect on the same model; this page covers SMS. You keep your CPaaS account, and you get the layer above it that a single provider account does not give you.
What people send on it
In practice the channel is carrying one of a handful of message types. Each has its own page covering what the message has to carry, how it should be paced, and what is worth recording afterwards.
One-time passwords
Your login depends on a code landing before the session expires. Connect the accounts you already pay for and the platform paces each code to the number it leaves from — so a burst of logins drains at the speed your numbers allow instead of queueing behind one shared quota.
Read more →Appointment reminders
A reminder earns its place by arriving early enough to change a plan and saying only what the person needs to act on: when, where, and how to change it. Send a confirmation at booking and a timed reminder before, on the number they booked with.
Read more →Service and incident alerts
An incident alert arrives when something is already wrong — the worst possible moment to discover your send path is down too. Keep more than one connected account on that channel, and the notice about the outage is not its first casualty.
Read more →What sits on top
Routing and failover
Ordered connections with per-connection weights across sender numbers. A provider that keeps rejecting sends is taken out of rotation instead of being retried forever.
Read the guide →Pacing to your real quota
Each connection carries a send rate and the platform queues to it. A throttle is treated as a pacing signal, not as a failed send.
Read the guide →Delivery receipts
Provider callbacks are normalized into one status vocabulary, with the raw provider code kept alongside. Terminal outcomes only.
Read the guide →Opt-out suppression
A reply of STOP writes a suppression record, and a check runs before each marketing send. Enforcement is fail-closed by default for marketing traffic.
Read the guide →Encoding and segment accounting
GSM-7 or UCS-2, decided per connection, with the billable segment count kept on the record so it can be reconciled against your provider invoice.
Read the guide →Bring your own account
The platform holds no provider account. Your credentials, your quota, your numbers, your invoice.
Read the guide →Where it plugs in
6 SMS providers can be connected self-service today, each with the credential fields it actually needs listed on its own page. Beneath the self-service set is an SMS adapter library of 33 adapters; those outside the listed set are unlocked on request rather than self-service, so we describe them as a different thing.
Scope. What is SMS-specific, and described on this page: routing and automatic failover, per-number pacing, and encoding / segment accounting. Delivery receipts are normalized on all three channels — every SMS provider, Resend on email and Meta on WhatsApp — and opt-out suppression is applied to marketing sends on all three, with the automatic STOP-keyword path being the SMS one.
How a send works
You hand us a message
Through the console or the API, naming the recipient, the content and — for marketing traffic — the message type that decides whether the suppression check applies.
We pick a route
The healthiest, highest-priority connection that is still inside its pacing budget takes the message. Sender numbers on that connection rotate by weight.
We call your provider
With your credentials, against your account, at the rate your quota allows. Nothing is sent on our account and nothing lands on our invoice to your provider.
We record the outcome
The provider acceptance, and later its delivery receipt, are recorded against the message with the error code normalized. Message bodies are not stored.
What stays with your provider
The account is yours, so these stay on your side of the line. We hand every message over correctly and report what came back — the carrier relationship is the provider’s job.
- Registering sender IDs, numbers or short codes with carriers
- The quota your provider grants your account
- Reach to a given handset, which depends on the destination carrier