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.

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