SMS channel

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 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 normalised 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 adapter library covering 33 SMS providers; those outside the listed set are unlocked on request rather than self-service, so we describe them as a different thing.

Scope. Routing and failover, delivery receipts and opt-out suppression are implemented on the SMS channel. Email and WhatsApp connect through their own pipelines, each with its own credentials and provider-side limits.

How a send works

  1. 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.

  2. 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.

  3. 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.

  4. We record the outcome

    The provider acceptance, and later its delivery receipt, are recorded against the message with the error code normalised. 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