Skip to main content

​
Opt-Out Keyword Alias Table

A contact who wants off your list may not type STOP — they may type BAJA, DUR, PARAR, or ARRÊT. If your keyword matching only honours one language, that request never turns into a suppression and every message your staff sends afterwards is a compliance exposure. This page is the reference for exactly which localized opt-out and opt-in aliases Orbit recognizes out of the box, and how to extend the set with your own.
These controls are tenant-owned — you decide which keywords count as an opt-out inside your account. Nothing on this page is a platform-mandated or global compliance gate: the shipped defaults are a deterministic seed you can prune in the editor, and anything you add is additive to what ships.

​
Scope and storage

Orbit keeps two relevant opt-keyword groups: an opt-out set (unsubscribes the sender — STOP family) and an opt-in set (re-subscribes after a prior opt-out — START family). A third group — help — triggers a regulatory auto-reply, not a consent change, and is documented on Custom Opt-Out Keyword Lists. The language labels and markets shown below belong to the same group a rule is in: a STOP alias in the opt-out group behaves identically to the seed STOP, and a START alias behaves identically to the seed START. Keyword rules are stored per tenant in a workspace-scoped record. Every tenant seeds the same deterministic default set on first open; after that you own the list. Because opt-out and opt-in rules are also keyword rules, the same record carries your custom alias additions and the seed rows as a single editable table. The language is stored as a label on each rule row, derived from the keyword text, and is a hint for your team — not a routing scope. A contact with a STOP rule in the opt-out group gets recognized as opting out everywhere; you do not filter a Spanish-language rule to only fire on Spanish contacts. The alias table below covers the canonical opt-out aliases (the set the server-side inbound matcher applies on every inbound reply before your rules run). The dashboard editor’s seeded rows give you a small curated subset of that same vocabulary as an editable starting point; adding one of these aliases back as a custom rule after you pruned it is a supported, additive edit.

​
Canonical STOP alias table

The table below lists every opt-out keyword Orbit ships by default, grouped by language, together with the markets where that alias is common. Matching is locale-insensitive case-folding with Unicode normalisation — accents, unexpected capitalization, and zero-width characters are normalised away before comparison, so any variant of the text below fires on any variant of the reply. The symmetric opt-in set is the re-subscribe vocabulary (the START family):
The matching rule runs against the exact keyword, or the keyword followed only by whitespace and a trailing punctuation mark (STOP. and Stop! both match). A longer message — STOP PLEASE, STOP AT ANY TIME — does not match: the carrier convention treats the keyword alone as the opt-out.

​
How aliases propagate across SMS, WhatsApp, and RCS

A rule only fires on the channel it is stored with: sms, whatsapp, rcs, viber, or email. The shipped seed defaults are scoped to the sms channel, because inbound SMS on a long-code or short-code number is the classic opt-out carrier surface; WABA / RCS opt-outs you handle through the same keyword mechanism by adding a rule on the whatsapp or rcs channel. When any opt-out rule matches — built-in or one of yours — the suppression Orbit writes is scoped to all, not sms. The entry in the suppression list is channel-all on the reply-capable phone number, so a STOP received on an SMS number blocks that number on the SMS and WhatsApp and RCS side at once. This is deliberate: the recipient’s STOP is a request to stop being contacted, not a request to stop being contacted on SMS. The propagation happens at the suppression record, not in the alias table — the alias vocabulary is the same on every channel; only the scope annotation of the stored rule differs.

​
Telegram: slash-command opt-outs

Telegram recipients do not type free-text keywords — they tap bot commands. Orbit honours Telegram opt-outs through a dedicated slash-command matcher that runs on every inbound Telegram message, separately from the alias tables above. The vocabulary follows Telegram bot convention rather than your rules editor: Matching is case-insensitive and looks only at the first token of the message: /stop, /STOP and /stop please remove me all opt the chat out, while I would like to /stop does not, because the command must lead the message. Trailing text after the command is ignored. In a group where your bot receives messages, Telegram clients address the bot as /stop@YourBotName; Orbit strips the @username suffix and honours the bare command, so the same four commands work in private chats and groups alike. An opt-out sent inside a group applies to that group’s chat; one sent in a private conversation applies to that private chat.

​
What each command writes

An opt-out command adds an entry to your suppression list scoped to the telegram channel, addressed by the chat id, with the triggering command recorded as the entry’s reason. The entry appears in the suppression ledger export and under the telegram channel filter of the Opt-outs console. A repeat /stop from an already-suppressed chat changes nothing. The bot then replies “You’re unsubscribed. Reply /start to opt back in.” — the acknowledgement is sent directly, so it reaches the chat even though the chat is now suppressed. A contact.opted_out webhook also fires to your active endpoints, carrying the chat id as the identifier. /start revokes the active entry for that chat instead of deleting it, so the ledger keeps the out-then-in history for audit. It fires contact.opted_in, and the bot sends its welcome-back reply. A /start from a chat that was never suppressed writes nothing and gets no welcome-back reply. Group membership events are a separate surface: the bot being added to or removed from a group, members joining or leaving, and join requests show up as unified-inbox events and never write or revoke suppression entries. Removing your bot from a group does not opt anyone out.

​
How Telegram scope differs from a phone-number STOP

A STOP received on SMS suppresses the phone number with scope all, fencing SMS, WhatsApp and RCS at once — see How aliases propagate across SMS, WhatsApp, and RCS. A Telegram /stop cannot propagate that way: the only identifier Telegram hands Orbit is the chat id, which does not correspond to a phone number, so the entry fences your bot messages to that chat and no other channel. To suppress the same person everywhere, record the opt-out against their phone number or email address through a phone- or email-keyed entry point — the Consent API or Preference Center (both write scope all), a bulk CSV import, or the console. The Telegram entry then stays on the ledger as the audit record of how the bot-channel revocation arrived.

​
Why the commands are not in your rules editor

The Opt-out Rules editor and POST /api/v1/settings/opt-out-rules cover the free-text channels — sms, whatsapp, rcs, viber, email — where synonyms are yours to seed, prune and extend. Telegram’s four slash commands ship with the channel and are recognised on every inbound Telegram message whether or not you have touched the editor. That split is additive, not a mandate layered over your list: the commands only ever add one more way for a recipient to revoke consent on the bot channel; they cannot prune, rename or weaken any alias you own, and your custom synonyms plus the seeded STOP / START sets keep firing on the editable channels exactly as described above.

​
Adding your own synonyms

Custom additions are additive-only. TCPA and CTIA require STOP (and START on the re-subscribe side), so the seeded STOP and START aliases can never be removed by a tenant edit. Everything else is yours to prune or extend. To add a custom synonym in the dashboard, open Messages → SMS → Opt-out Rules and add a new row. Put your alternate vocabulary word in the Keyword field (uppercase is stored, but inbound matching is case-insensitive) and the acknowledgement text in Auto-reply. Save the row; the new synonym fires immediately against inbound SMS on every reply-capable number in your account. The same editor is used to add a localisation alias, a branded synonym, or a screen keyword some of your recipients use that the seed defaults don’t cover. Workspace roles gate write access: owner or admin may create and save rules. Team members with billing, viewer, or supervisor roles see a read-only view instead of the editor. Over the API the equivalent is POST /api/v1/settings/opt-out-rules, documented in the Settings API reference under keyword & opt-out rules. Supply the keyword, the channel (sms / whatsapp / rcs / viber / email), the action (opt-out or opt-in), and an optional auto_reply_text.
Custom synonyms succeed because they widen the trigger surface; they do not unblock a contact that a real opt-out list or the suppression list already blocked. A custom keyword matches before a keyword rule, alongside the opt-out / opt-in groups — you can add vocabulary, not soften the mandatory STOP path.

​
Exporting or viewing the effective list

The Opt-out Rules page renders the entire effective set — seeded defaults plus your additions — as an editable table, with each row showing its stored channel scope, the derived language and market label, and the reply copy. Delete a row to prune an alias; add a row to extend. Use that page rather than guessing which vocabulary your workspace actually honours today, because the page is the source of truth for every inbound reply your numbers will match. Over the API, the same list is returned by GET /api/v1/settings/opt-out-rules (or GET /api/v1/settings/keyword-rules when you want keyword-triggered replies that act on opt-out / opt-in actions). Both endpoints paginate. There is no separate export format — the list body is what you act on. For the audit-position view of suppression entries (the addresses keywords have actually suppressed, and the scope they carry), see Opt-Out & Suppression Lists. The keyword list enumerates the trigger vocabulary; the suppression list enumerates the results.

​
Where to edit in the dashboard

Every prompt to edit aliases should land on Messages → SMS → Opt-out Rules — a dedicated route in the workspace, not an overlay on the SMS inbox. The rules are account-wide, apply to every inbound-reply-capable number, and persist across sessions exactly as you saved them. Use the route to make a real edit you can later prove fired by texting one of your numbers.