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