Opt-out management on a CPaaS
SMS opt-out management is the machinery that turns a recipient's "stop" into an enforced fact — a keyword reply, an unsubscribe click, or an imported legacy list becomes a suppression entry, and the suppression list is the hard send-gate every later campaign, import, and API call has to clear. On a CPaaS the two objects are distinct: the opt-out record is the auditable consent ledger, and the suppression list is what the sending pipeline actually enforces.
The opt-out (STOP compliance) glossary entry defines the term; this guide covers how the management surface runs end to end on Devotel Orbit — the keyword layer, the cross-channel suppression scope, the rules editor you own, and the two intake paths (preference center and CSV import) that feed the list. It is the deep companion to the opt-out section of the CPaaS compliance topics overview, which treats the topic at procurement-survey depth.
STOP/START keyword semantics and carrier expectations
US carriers and the CTIA messaging guidelines require every A2P program to honor a standard keyword set on every campaign: STOP must revoke consent and stop further messages, START (or UNSTOP) re-enables a recipient who previously opted out, and HELP returns program contact information. The semantics are asymmetric on purpose: an opt-out keyword must produce an immediate, durable suppression (the receipt the sender owes the recipient is the confirmation text), while an opt-in keyword only works on a recipient with a prior opt-out on record — a START from someone who never opted out changes nothing.
On Orbit this base layer runs at the platform: STOP handling is carrier-mandated and no tenant setting removes it, so a campaign can never depend on hand-rolled keyword parsing. Everything a tenant configures on top is additive — custom aliases widen the trigger surface, they never narrow the carrier-required set. The mechanics, including how to prove a rule fired and why alphanumeric senders can never receive keyword replies, are in the docs guide to SMS opt-out & opt-in rules.
Why one suppression list matters across SMS, WhatsApp, and RCS
Multi-channel sending leaks compliance risk at the channel boundary: a recipient who texts STOP to your SMS number and then receives your WhatsApp template the next morning has, from their side, received exactly the message they asked you to stop. Orbit models this with a channel scope on every suppression entry, and the scope is inferred per entry point. A STOP keyword reply, a preference-center unsubscribe, or a Consent API opt-out always writes scope all — one identifier suppressed everywhere it is reachable, across SMS, WhatsApp, RCS, voice, and the remaining channels; the voice and dialer gates read the same list, so an opted-out phone number stops receiving calls as well as messages. Only the bulk CSV import infers scope from the row's address type — phone and WhatsApp rows land at scope all, email rows at scope email — and a per-row channel column can override either default.
The single-list design is what makes cross-channel honoring an enforced property rather than a sync job: there is one suppression ledger per tenant, written by every intake path and read by every send gate. The full scope set, the per-entry-point scope inference, and the DNC mirror for bulk imports are in the Opt-Out & Suppression Lists reference.
The shipped localized alias vocabulary
A recipient who wants off your list may not type STOP — they may type BAJA, DUR, PARAR, or ARRÊT. Orbit ships a canonical alias vocabulary across nine languages (English, Turkish, German, Spanish, French, Portuguese, Italian, Arabic, Dutch) plus the symmetric opt-in set (START, BAŞLA, ALTA, INICIAR, and the rest), matched with locale-insensitive case-folding and Unicode normalisation so accents and stray capitalization are normalised away before comparison. The server-side inbound matcher applies that canonical set on every inbound reply — so a Turkish DUR suppresses exactly like an English STOP with no tenant configuration — and the Opt-Out Keyword Alias Table is the authoritative reference for the full list.
Two points operators get wrong most often. First, the language label on a keyword is informational, not a routing scope: the matcher does not filter a Spanish alias to Spanish contacts. Second, the shipped vocabulary is a floor, not a ceiling — the next section is where you add your own.
The tenant-owned rules editor
Keyword rules beyond the platform set live in a dedicated editor — Messages → SMS → Opt-out Rules — a tenant-owned control restricted to owner, admin, and developer roles. Each rule is one keyword plus the auto-reply it sends, in an opt-out group (unsubscribe) or an opt-in group (re-subscribe); first open seeds a curated multilingual default set (STOP/UNSUBSCRIBE/CANCEL/QUIT/END plus ALTO, STOPPER, SCHLUSS, PARAR, DUR/IPTAL/RED and their opt-in pairings) that you prune or extend. Rules apply account-wide on every reply-capable number, edits are local until saved, and a keyword match writes to the contact's consent history so the receipt is auditable.
The discipline that matters operationally: keep at least one opt-out path per language you actually send in, and test a keyword on a real handset before a campaign depends on it — the docs guide walks the suppress → attempt-send → opt-back-in round trip end to end. Per-service keyword lists for individual messaging services are a separate surface, covered in Custom Opt-Out Keyword Lists.
Preference center and CSV import: the two intake paths
Keyword replies catch the recipients who respond to a message. Two further intake paths serve everyone else.
The preference center is a hosted, public opt-in/opt-out page each contact reaches through a signed, per-contact link (30-day token expiry) — no account, no login. You configure the channels, subscription topics, frequency options, and branding once, publish the link under your footer or privacy policy, and every opt-out the page records writes the same all-scope suppression an SMS STOP writes, so the self-serve channel and the keyword channel can never disagree. The full walkthrough is the preference center guide.
CSV import is the migration path: a legacy platform's suppression list arrives as one multipart/form-data upload (≤ 25 MB, ≤ 100,000 rows) to the suppression-list import endpoint, with dry-run previews, per-row results, deduplication, and a default_country that normalises national-format numbers to E.164. Import infers the scope from each row's address type — phone and WhatsApp rows at scope all, email rows at scope email, with a per-row channel column to override — and phone rows are additionally mirrored onto the DNC list so the voice gates honor a migrated phone suppression the same way; the suppression reference covers the accepted header aliases and the audit export back out.
None of this manufactures consent outcomes for you — suppression and keyword rules are tenant-owned controls: your account decides what qualifies as an opt-out, and the platform enforces the decision at the send gate with the evidence trail attached. The one platform-level exception is the carrier-mandated STOP/START handling described above, which no tenant setting can remove. For the step-by-step mechanics, work through the docs:
- Opt-Out & Suppression Lists — scopes, bulk import, enforcement verification, and export.
- Opt-Out Keyword Alias Table — the canonical shipped vocabulary and how to extend it.
- SMS opt-out & opt-in rules — the account-wide keyword editor and the round-trip test.
- Custom Opt-Out Keyword Lists — per-messaging-service keyword lists.
- Preference center — the hosted self-serve opt-in/opt-out page.
Frequently asked questions
What keywords must an SMS program honor on US carriers?
STOP (and its CTIA-standard companions such as STOPALL, END, CANCEL, QUIT, and UNSUBSCRIBE) must revoke consent, START or UNSTOP re-subscribes a previously opted-out recipient, and HELP returns program contact information. On Orbit this base set is enforced at the platform layer for every tenant; anything configured in the rules editor is additive on top of it, never a replacement.
Does an SMS opt-out apply to WhatsApp and RCS too?
Yes, always. A STOP keyword, preference-center unsubscribe, or Consent API opt-out records scope all, which the SMS, WhatsApp, RCS, voice, and dialer send gates all read — one suppression entry removes the identifier from every channel it is reachable on. Only a bulk CSV import narrows the scope by address type: it scopes email-address rows to email (phone and WhatsApp rows still land at all), and a per-row channel column can override the inference either way.
Can I suppress STOP handling or narrow the carrier keyword set?
No. The carrier-mandated STOP/START handling runs at the platform layer and no tenant setting removes it — TCPA and CTIA require it regardless of configuration. The rules editor is additive only: you can widen the trigger surface with aliases and branded opt-ins, but deleting every custom row still leaves the platform set intact.
How do I migrate a suppression list from a previous platform?
As a single CSV import to the suppression-list import endpoint: up to 25 MB and 100,000 rows, case-insensitive header aliases, a dry-run mode that parses and classifies without writing, per-row results, and deduplication against existing entries. Run the dry run first, then commit; the ledger exports back out for audit.
Sources and further reading
- Opt-Out & Suppression Lists: channel scopes, bulk CSV import, enforcement, and the audit export.
- Opt-Out Keyword Alias Table: the canonical nine-language opt-out and opt-in vocabulary.
- SMS opt-out & opt-in rules: the account-wide rules editor, seeded defaults, and the suppress → send-gate → opt-in round trip.
- Preference center: the hosted, token-signed public opt-in/opt-out page.
- CTIA Messaging Principles and Best Practices: the carrier-industry baseline the keyword semantics answer to.
- CPaaS compliance topics: the procurement-depth companion — TCPA, 10DLC, STIR/SHAKEN, and opt-out handling in one survey.