Skip to main content

​
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; 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. 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): 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. 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