Skip to main content

​
Opt-Out Entry Points by Channel

A revocation request arrives on whichever channel your contact happens to be using. On some channels Orbit recognises and records it on its own; on others nothing parses a STOP, so the request only becomes a suppression entry when your team logs it. This page lists, per channel, what is recognised automatically, what each path writes, and exactly how to record revocations that arrive on channels without automatic recognition.
These are tenant-owned controls. The matrix below describes what the platform recognises today; the keyword vocabulary on the editable channels remains yours to seed, prune and extend per the alias table, and the manual logging procedure for the non-automated channels is your team’s to run.

​
Per-channel recognition matrix

The scope column is what the send gates read: an all entry fences the address on every channel, a single-channel entry fences only that channel, and a telegram entry fences your bot messages to that chat. The scope semantics are documented in Consent Management; this page covers where the revocation enters, not what the scope means once stored.

​
Channels without automatic recognition

On LINE, Instagram, Messenger, WeChat, Kakao, Zalo and Apple Messages, an inbound STOP (or any other revocation phrasing) creates no suppression row and sends no confirmation. Two structural reasons, the same ones that bound the Telegram slash commands:
  • Those connectors hand Orbit the app’s chat or user identifier, not a phone number. There is no number on the inbound event to fence.
  • No keyword parser runs on those inbound paths, so even a textbook STOP is just a message your team receives in the unified inbox.
Because the identifier is a chat id, do not try to suppress the chat: record the revocation against the customer’s phone number or email address — the address your campaigns actually target — so the fence covers every channel with scope all. The call is the same one documented in the Consent Management worked example. Set source to a tag your team audits against, for example inbound_keyword when the request arrived as a keyword in an app chat:
An opt_in: false on a phone identifier writes scope all, the same fence a keyword STOP writes on SMS.

​
Or use the surfaces your team already works in

  • Preference Center — record the revocation the same way a self-service subscriber would: Preference Center.
  • Bulk CSV import — for a backlog of app-chat revocations collected over a period, import them in one pass with an explicit channel or scope per row: bulk CSV import.
Whichever path you use, the entry lands in the same ledger as automated revocations and reads back identically — see Verify every revocation landed.
Log the revocation while the conversation is still open. On the non-automated channels the request sits in your unified inbox as an ordinary message; once the thread scrolls away, nothing reminds anyone that consent was withdrawn. Put the logging step in your agent scripts — the next section shows the shape.

​
Put the logging obligation in your agent scripts

On the non-automated channels, the first person to see a revocation is usually one of your agents in the inbox console. Agent scripts are the tenant-owned tool for making the logging step part of the flow instead of a matter of memory: add a step to the scripts that run on those channels instructing the agent to record the revocation before closing the conversation. A step of this shape works in any script:
Voice is handled on its own surface: verbal objections on live calls belong to the voice queue scripting surface, not to inbox agent scripts.

​
Verify every revocation landed

For every revocation, automated or manually logged, close the loop with a read-back before you rely on it in a campaign:
  1. Consent history. GET /api/v1/compliance/consent/history?identifier=<address>&channel=<channel> shows the newest row with consent_state: "opted_out" and a revoked_at — the no-send-after instant you present in an audit.
  2. Suppression export. Export the ledger from Opt-Out & Suppression Lists with status=active and confirm the address is listed with the scope you expect (all for a phone-keyed revocation).
  3. Opt-outs console. The Opt-outs console channel filters isolate the slice per channel when you want the dashboard view instead of the export.
For the automated channels, prove the path end to end with a real inbound, the same discipline as the keyword rules testing checklist: send the keyword from a test handset or chat, confirm the confirmation reply arrives, confirm the consent history row and the scope-all suppression entry. For a non-automated channel, run the negative case once per connector you operate: send STOP from a test account, confirm that no suppression row appears (that absence is expected and is exactly why the manual procedure above exists), then log it through the Consent API and confirm all three read-backs.