Feature · SMS channel

Opt-out and suppression, applied where they belong

Suppression is the part of messaging that is easy to get almost right and expensive to get wrong: honour it too broadly and confirmations stop arriving; honour it too narrowly and you are ignoring a customer who asked you to stop. Getting it right is the whole feature.

Promotional traffic only

Opt-out suppression is applied to promotional traffic. Transactional messages — a one-time code, a delivery notice — are not suppressed by the same rule, because a customer who opts out of marketing has not asked to lose their login code.

Matching is exact on purpose

Opt-out keywords are matched exactly rather than fuzzily. A loose match catches “STOP” inside unrelated text and silently suppresses a customer who never asked for it, which is a worse failure than the one it prevents.

  • Opt-out keywords honoured per the rules you configure
  • Promotional sends filtered against the suppression record
  • Transactional sends unaffected

Built end to end on the SMS channel

This pipeline ships on the SMS channel, where opt-out keywords are part of how the channel works. Consent — who agreed to be messaged, when, and how that is recorded — stays on your side; the platform applies the suppression it is given, exactly as configured.

Questions this usually raises

Will opting out stop a customer’s verification codes?
No. Suppression is applied to promotional traffic, not to transactional sends.
Can someone be re-subscribed?
Yes, and the resubscribe path is deliberate rather than implicit — it is covered in the guides and should be used whenever a customer asks to be contacted again.
Is suppression available on email and WhatsApp?
The opt-out and suppression pipeline described here ships on the SMS channel today.

Keep reading

7 min

Opt-out handling

Opt-out is two halves: the suppression record, and the check that runs before a marketing message is handed to the provider. Both run through one shared normalisation, which is the part that usually breaks.

Read the guide →
4 min

Who decides whether a message is marketing

The platform asks you to declare what kind of message you are sending instead of inferring it from the text. That one field decides whether the opt-out gate applies — and the honesty of the declaration is yours.

Read the guide →
Features

Bring-your-own provider connections

You keep the provider relationship you already have, connect it once, and the platform treats that account as a send path it can route through, pace against and read receipts from.

Open →
Features

Routing and automatic failover

One provider account is a single point of failure that you cannot see failing until customers tell you. Routing across several accounts turns that into a failover you configure once.

Open →
Features

Normalised delivery receipts

Two providers describe the same outcome with two different words, and neither word means what the reader assumes. Normalising receipts into one status is what makes a receipt usable in code rather than as a screenshot.

Open →
Features

Pacing at the provider’s real limit

The limit that stops your traffic is not your application’s quota — it is the rate your provider applies per sender number. One number, one limit, and a batch that ignores it fails partway through.

Open →
Features

Sender identity you own

The sender is the first thing a recipient sees and the thing that decides whether a message is trusted. Because that identity sits on your own account, it stays with you however you choose to send.

Open →
Features

Send API

Product messaging is emitted by code, not typed by a person. The API exists so the service that knows an event happened is the service that sends the message about it.

Open →
Features

Receipt webhooks

Polling for status works until the volume makes it wasteful. A callback lets the system that cares about an event be told about it, which also means the record lands in your own database at the same time.

Open →
Features

Message logs and usage

The first question after any messaging incident is “what did we actually send?”. That answer should come from a log with a filter on it, not from a reconstruction.

Open →
Features

Tenant isolation

Isolation is the feature that nobody asks about until it is missing. Holding connections, keys and records per tenant means a shared platform does not become a shared inbox.

Open →
Features

Manual sending from the console

Not every message comes from an API. Testing a new sender, resending after a fix, or simply looking up what a customer received — those are console jobs, and they should not require writing code.

Open →
Scope. Whaleal Messaging is an orchestration layer over the CPaaS or BSP accounts you already hold. Your contracts, your rates and your sender identities stay yours, and nothing in the middle reprices them. Each page states the channel a capability ships on, so you can plan against what is available today.