> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Wording regions: what Orbit injects into your outbound copy > The wording-injection model for outbound messages — how Orbit appends the carrier opt-out footer at render time, which phrasing ships per recipient locale, how consent keywords resolve inbound replies, and the tenant-owned overrides that adapt each region. # Wording regions: what Orbit injects into your outbound copy Not every word in an outbound message comes from the body you typed. Orbit attaches boilerplate wording at render time — most visibly the carrier-required opt-out footer on promotional SMS — and depends on matching keyword rules on the inbound side so a recipient's reply actually changes their consent state. This page defines that wording-injection model: what is appended, which phrasing ships per recipient locale, how inbound keywords resolve against it, and which levers you own. The scope is deliberately narrow. Carrier-reviewed template regions (WhatsApp `HEADER` / `BODY` / `FOOTER` / `BUTTONS` components) are covered under the [template lifecycle](/concepts/template-lifecycle); the rules Meta enforces per component (60-char footer cap, OTP template restrictions) are validation concerns, not wording injection. This page covers the wording the platform stitches in around your authored body — wording you did not type but your recipient sees. ## What Orbit appends to an outbound body The attached wording falls into two families, and distinguishing them is the first modeling decision: * **The marketing opt-out footer (SMS).** Every template in the SMS gallery whose `kind` is `marketing` carries the directive `appendStopFooter: true`. At render time the platform appends the carrier opt-out sentence — "Reply STOP to opt out." in the English default — after your body, separated by a single space. Transactional and informational templates (OTP, receipts, appointment reminders) carry no footer; they are exempt from the promotional opt-out directive under carrier policy. The presence of the footer on a marketing send is not configurable — you cannot remove it from a gallery-backed promotional template. * **Consent prompt wording (SMS and email).** The managed double-opt-in handshake composes its own confirmation prompt — the CTIA §5.1.3 sample phrasing carriers expect at 10DLC review ("Reply YES to subscribe. Msg & data rates may apply. Msg freq varies. Reply STOP to opt out."), and a parallel email-native variant when the handshake is delivered over email instead. This wording is fixed: the SMS variant is length-audited so a brand name that would push the prompt past one segment falls back to the no-brand form rather than billing you for a second segment. Both families resolve only at send time. The stored template body never contains the footer — it is appended when the message renders, so the same template object serves every recipient locale without forking your library. ## The opt-out footer catalog Six locales ship a vetted default phrasing, keyed by the recipient's base ISO 639-1 locale (region suffixes like `fr-CA` collapse to `fr` before lookup): | Locale | Footer appended | Governing guidance | | - | - | - | | `en` (default) | Reply STOP to opt out. | US CTIA Short Code Monitoring Handbook §5.1.7 | | `es` | Responde PARAR para anular. | LATAM carrier guidance (`PARAR` honored in MX, AR, CL, CO, PE) | | `fr` | Répondez ARRÊTER pour vous désinscrire. | France ARCEP recommendation | | `de` | Antworten Sie STOPP zum Abbestellen. | Bundesnetzagentur (`STOPP` honored by Telekom and Vodafone DE) | | `pt` | Responda PARAR para cancelar. | Anatel BR / ANACOM PT | | `cn` | 回复 退订 取消订阅. | China MIIT (`退订` is the mandatory keyword) | Each row is the entire footer — nothing else is appended. Two properties decide how the footer affects the rendered message: * **Segment math.** `en`, `es`, and `pt` are GSM-7-safe and typically stay inside the same segment your body occupies. `fr` and `de` carry diacritics that force UCS-2 encoding, and `cn` is UCS-2 by definition — so a localized footer can move a recipient into the multi-segment band. The composer flagging `multiSegment: true` on a gallery template is the early warning; the live segment counter in the composer is the authoritative read. * **Duplicate-safe assembly.** When a variant generator or a hand-authored body already contains an opt-out sentence, the append step dedupes it — the rendered message carries the footer once, with the separator it peeks at removed, rather than stacking two opt-out sentences back to back. If you are operating in a market where no bundled phrasing exists, the recipient falls back to the English default — and you should file that gap as an override (below), not edit the body to compensate. ## How inbound consent keywords resolve Appending "Reply STOP" is only half the contract — a recipient's reply must actually flip their consent state. The platform runs a canonical keyword matcher on inbound (MO) messages that recognises opt-out, opt-in, and help intents with these properties: * **Multilingual matching.** Carrier mandates diverge by market — US CTIA requires `STOP`/`STOPALL`, Turkish KVKK/BTK requires `RED`, German UWG requires `STOPP`/`ABBESTELLEN` — so every locale's keyword set is consulted. When no language hint exists, the universal set plus every language's keywords run as fallthrough. Cover the variants your audience uses; the footer you append declares the keyword the matcher must catch. * **Zero-width defang and locale-pinned folding.** Invisible characters (ZWSP, bidi controls) are stripped and case folding is pinned to `en-US` before comparison, so a copy-pasted `ST‍OP` or a Turkish-locale Node process cannot let an opt-out slip through. * **Boundary semantics.** The keyword matches as a complete word — `STOP.` and `STOP` match, `STOP PLEASE` does not (carrier convention is the keyword alone). Multi-word keywords like `opt out` are supported once internal whitespace collapses. On WhatsApp the same consent vocabulary applies through the channel's own inbound webhook: a matched opt-out keyword writes suppression on the contact, and no further promotional sends render until a new opt-in arrives. The footer phrasing you confirm during template review must therefore name a keyword your channel's matcher recognises — a footer telling recipients to reply `UNSUBSCRIBE` while the matcher only knows `STOP` is a wording defect the recipient cannot escape. ## Tenant-owned overrides Two settings under your organization's `compliance` node adapt the footer region. Both are opt-in, tenant-owned controls — the platform defaults are conservative so a cold launch never silently changes your segment costs: * **`localized_stop_footer_enabled`** (boolean). When `true`, the footer catalog above resolves the footer in the recipient's locale. When absent or `false`, every footer appends the English default regardless of locale — segment-identical to the historical behavior. * **`stop_footer_overrides`** (per-locale map). A `{ locale: "custom phrasing" }` object consulted before the bundled catalog, so a market your legal team has vetted different phrasing for ships that phrasing instead of the platform default. Resolution order is fixed: override map → bundled catalog → English fallback. Set the enable flag first; without it the override map is never consulted. Because these live under tenant-controlled compliance settings, a marketplace of one tenant's phrasing never bleeds into another tenant's sends. Custom merge-tag placeholders (`{{first_name}}`, `{{order_id}}`) resolve through a different path — the gallery renderer leaves unknown tags as the literal `{{tag}}` so an operator fills them before send, and a template's declared `variables` list must match its extracted tag names. Never route a footer override through a merge tag; the resolution chain above expects a static string. ## Troubleshooting boilerplate that looks wrong * **The footer is missing on a promotional send.** The template's `kind` is not `marketing` — transactional and informational templates carry no footer by design. If the send is promotional in substance, re-author it from a marketing-kind gallery entry so the directive attaches. * **The footer is English for a known French recipient.** The `localized_stop_footer_enabled` flag is unset. Locale adaptation is opt-in; set the flag under compliance settings and re-render. * **One message bills for two segments after enabling localization.** Expected on `fr`, `de`, and `cn` recipients — the diacritics force UCS-2. The per-recipient segment cost is the trade the compliance correctness costs; the enable flag exists precisely so you take that trade deliberately. * **Two opt-out sentences render back to back.** Your body or a variant already contains one — rewrite the body to drop it and let the append step own the single footer. The dedupe guard handles the common duplicated-sentence shapes, but the cleanest fix is one canonical footer source. * **A recipient replied STOP and sends continue.** The footer told them to reply a keyword the matcher does not recognise for that channel, or your inbound keyword rules are disabled at the channel level. Check the active rule set under Settings → Auto-Reply Rules before re-sending. ## See also * [Template lifecycle](/concepts/template-lifecycle) — the carrier-reviewed component regions (HEADER / BODY / FOOTER / BUTTONS) this page deliberately excludes. * [Keyword auto-reply and opt-out: the matching model](/concepts/keyword-rules-model) — full matcher semantics the footer keywords rely on. * [Consent and suppression model](/concepts/consent-and-suppression-model) — what a matched opt-out actually writes. * [SMS segments and encoding](/concepts/sms-segments-and-encoding) — the GSM-7/UCS-2 escalation the localized footers can trigger.