Bring your own account
The platform has no provider account of its own. That one design decision changes who owns the numbers, who holds the quota, and who appears on the invoice.
Read the guide →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.
The two halves
A suppression record is written when a recipient asks to stop. The record belongs to a tenant, a channel and an address, and it is written idempotently: a repeated opt-out refreshes the existing record rather than creating a second one.
The check runs before a marketing message is handed to the provider. If the address is suppressed, the message is not sent and the outcome is recorded as suppressed rather than as a failure — it was never attempted, so counting it as a delivery failure would be wrong.
Which replies count as an opt-out
The recognition list follows the North American carrier standard: STOP, STOPALL, UNSUBSCRIBE, CANCEL, END and QUIT. OPTOUT and OPT OUT are included as widely supported variants. Because the messages the platform sends are not always in English, the local-language equivalent that appears in its own opt-out footer is recognised as well — so a recipient who replies in the language they were written to is not left subscribed.
The matching is exact, and that is deliberate
Before matching, the reply is normalised: case is folded and punctuation is collapsed to spaces. Matching then requires the whole normalised reply to equal a keyword. It is not a substring search.
Substring matching would classify a reply like "please do not stop the promotion" as an opt-out, silently ending the conversation with a customer who asked for the opposite. The cost of exact matching is that an unusual phrasing such as "STOP please" is not auto-recognised — that one goes to a human, and the console can add it to the suppression list by hand.
Coming back: START, YES and UNSTOP
Opt-out is required to be reversible. START, YES and UNSTOP are treated as the reverse action: the suppression record for that address is deactivated and a confirmation is sent back.
The confirmation goes out as transactional rather than marketing traffic. That ordering matters: if the recipient is still suppressed at the moment the confirmation is composed, a marketing classification would be blocked by the very gate it is confirming.
HELP is a separate branch, and it is always answered
Replies that ask for help are answered with an explanation, and that reply is sent even to an address that has already opted out. A recipient who asked to stop and then asked for help is still entitled to the help text.
Two limits you should know about
- Some provider-side opt-out handling is carrier-level. A reply to STOP may be handled by the carrier and never delivered to the platform as an inbound message at all. Where that is the case, the platform recognises the traffic pattern and logs it distinctly rather than pretending it has handled something it never saw.
- Deactivating a record is a database change, and it is not the same as being deliverable again. On some sender types the carrier may have blocked the number on its own side; restoring the record does not undo that, and the carrier has to release it.
One normalisation, used by both sides
The write path and the read path share the same address normalisation. This is the detail that decides whether the feature works at all: if the record is written under one spelling of a number and the check queries another, the gate silently stops matching, nothing errors and nothing turns red, and the recipient keeps receiving messages they opted out of.
Scope. Suppression is implemented for the SMS channel and is the only channel where it is enforced today. Do not assume it carries across to email or WhatsApp.
Keep reading
SMS segments and what you actually pay for
SMS is billed per segment, not per message. Whether your text fits in one segment depends on the character set it needs — and on the encoding you set on the connection.
Read the guide →Reading a delivery receipt
A receipt is a sequence of states, not a verdict. Treating an intermediate one as final is the most common way a sending dashboard ends up lying to you.
Read the guide →Pacing, quotas and why we queue
Every connection carries a send rate. The platform queues to that rate instead of firing as fast as a provider will accept, because the fastest way to get throttled is to send at the speed that causes it.
Read the guide →Routing and failover
Routes are ordered by priority and weighted within a connection. The point of the arrangement is that a provider rejecting sends degrades into slower sending, not into silence.
Read the guide →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 →A timeout is not a failure
Sending is accepted asynchronously and there is no de-duplication key. Retrying a request you are unsure about sends a second message and bills for it.
Read the guide →Two endpoints that look alike and are not
Delivery receipts and inbound replies are different endpoints, configured in different places in your provider’s console. Configure only the receipt URL and opt-out handling stops — silently, with no error anywhere.
Read the guide →Getting a number back
A recipient who opted out can opt back in. The platform deactivates the suppression record rather than deleting it, so the consent trail survives.
Read the guide →What happens when your callback is down
Terminal outcomes are pushed to a URL you control, with a small bounded retry. Your handler has to tolerate a repeat, and it should not expect a call for every message.
Read the guide →Which rate limit you just hit
There are two throttles in front of a send: the one your plan sets, and a much higher one at the network edge. Both answer with the same status code, so the message text is what tells them apart.
Read the guide →Who the recipient actually sees
If you do not name a sender, the platform picks one from the connection that carries the message. Naming one explicitly takes priority everywhere.
Read the guide →What the platform does not keep
Message content is not archived. What is kept is metadata — and among that metadata two fields are load-bearing, because without them a bill could not be reconciled.
Read the guide →