> ## 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. # Suppression vs Consent Precedence Model > How inbound suppression, explicit consent, quiet hours, and lawful-basis overrides interact across channels on Orbit when both exist for the same recipient. # Suppression vs Consent Precedence Model Operators frequently manage contacts who have both a recorded consent grant and an active suppression entry. For example, a customer may have checked a marketing opt-in box on a web checkout, but earlier sent a `STOP` text on SMS; or a customer may text `STOP` to opt out of promotional messages, and subsequently need an urgent one-time passcode (OTP) or password reset. This page defines the canonical precedence model: which state wins when suppression and consent conflict, how channel scopes govern enforcement, when non-consent lawful bases bypass marketing gates, and how inbound and outbound compliance mechanics differ. Compliance controls on Orbit are **tenant-owned**. Orbit serves as the conduit and system of record for your suppression lists and consent ledger. With the sole exception of the US TCPA federal voice dialing-window guard (invariant #68), compliance gates default open and are configured per tenant. This guide does not constitute legal advice. *** ## 1. Why Inbound vs Outbound Consent Differ Compliance mechanics operate under fundamentally different rules depending on message direction: * **Inbound requests (STOP family)** assert an immediate, unconditional right to halt contact. When a recipient texts a recognized opt-out keyword (`STOP`, `UNSUBSCRIBE`, `CANCEL`, `QUIT`, or localized synonyms documented in the [Opt-Out Keyword Alias Table](/compliance/opt-out-keyword-alias-table)), Orbit writes an inbound suppression entry with scope `all`. This suppression acts as an absolute block. It ignores any previously active consent records, bypasses marketing preference profiles, and prevents further standard outbound dispatches to that identifier. * **Outbound dispatches** require multi-layered evaluation before transmission. An outbound message or voice call does not simply query a single boolean flag. Instead, the dispatch pipeline evaluates: 1. **Suppression check**: Is the recipient identifier present on the tenant suppression list for the target channel or under scope `all`? If suppressed, the send is dropped immediately. 2. **Consent check**: If the tenant enforces affirmative consent (via `consent_required`), does an active, unexpired `opted_in` grant exist for this specific channel and message type? 3. **Timing and regulatory windows**: Is the message within permitted local hours according to tenant quiet-hours rules and statutory windows? 4. **Destination and sender rules**: Does the destination country or route enforce registration preflight checks (e.g., 10DLC campaign profiles, alphanumeric Sender ID registrations, or DLT templates)? Because inbound suppression represents an explicit revocation of permission by the data subject, it supersedes outbound consent assumptions across all shared communication paths. *** ## 2. Interaction Matrix: Suppression Scope vs Consent Scopes The table below illustrates how different suppression scopes interact with consent types and lawful bases when dispatching messages or initiating calls: | Suppression State & Scope | Consent State & Type | Message / Traffic Class | Lawful Basis | Dispatch Outcome | Enforcement Rationale | | :- | :- | :- | :- | :- | :- | | **Suppressed (`scope: all`)** | `opted_in` (Marketing) | Marketing / Promotional | Consent | **BLOCKED** | Scope `all` suppression strictly supersedes explicit marketing consent. | | **Suppressed (`scope: all`)** | `opted_in` (Transactional) | Marketing / Promotional | Consent | **BLOCKED** | Suppressed under `all`; marketing traffic cannot proceed. | | **Suppressed (`scope: all`)** | None or `opted_in` | Critical Transactional / OTP | Contract / Vital Interests / Service Exemption | **BLOCKED by default** | Inbound `STOP` suppresses the destination number across all standard pipelines. Critical service alerts require explicit opt-in re-grant (`START`) or dedicated exempt routing. | | **Suppressed (`scope: sms`)** | `opted_in` (WhatsApp) | WhatsApp Notification | Consent | **ALLOWED** | Suppression is isolated to SMS; WhatsApp consent is valid and unsuppressed. | | **Suppressed (`scope: email`)** | `opted_in` (SMS) | SMS Marketing Campaign | Consent | **ALLOWED** | Email suppression (e.g., List-Unsubscribe) does not affect SMS phone consent. | | **Suppressed (`scope: sms`)** | `opted_in` (SMS) | SMS Marketing Campaign | Consent | **BLOCKED** | Channel-specific SMS suppression overrides SMS consent grant. | | **Not Suppressed** | `opted_out` (Revoked) | Marketing Campaign | Consent | **BLOCKED** | No suppression record, but explicit consent is revoked (`opted_out`). | | **Not Suppressed** | `opted_out` (Marketing) | Transactional / OTP Alert | Contract / Service Exemption | **ALLOWED** | Transactional traffic under contractual basis is exempt from marketing consent revocation. | | **Not Suppressed** | Unknown / Missing | Marketing (Strict Consent Gate Enabled) | Consent Required | **BLOCKED** | Tenant enforces double opt-in / affirmative consent; missing grant blocks dispatch. | | **Not Suppressed** | Unknown / Missing | Marketing (Consent Gate Disabled) | Soft Opt-In / Default Open | **ALLOWED** | Platform defaults open for unconfigured marketing gates when no suppression exists. | *** ## 3. Worked Scenario: The STOP → START → Transactional Lifecycle Consider a common customer interaction lifecycle involving SMS order notifications and marketing offers: ``` [Day 1] Customer opts in via web checkout └── Recorded: consent_state='opted_in', consent_type='marketing', channel='sms' [Day 10] Customer receives promotional SMS and replies 'STOP' ├── Trigger: Canonical opt-out alias match ├── Action 1: consent_records updated with consent_state='opted_out', source='inbound_keyword' └── Action 2: suppression_list entry created with scope='all' for the E.164 phone number └── Result: Number is completely fenced. Marketing and standard sends are BLOCKED. [Day 12] Customer logs in and texts 'START' to re-subscribe ├── Trigger: Canonical opt-in alias match ├── Action 1: suppression_list entry for the number is removed └── Action 2: New consent_records row appended: consent_state='opted_in', source='inbound_keyword' └── Result: Number is unsuppressed. [Day 13] Tenant dispatches a Transactional Send (Order Confirmation / OTP) └── Evaluation: 1. Suppression check: Negative (cleared by START). 2. Consent check: Message categorized as 'transactional'. Under 'exempt_transactional: true', transactional messages rely on contractual basis and do not require active marketing consent. 3. Quiet-hours check: Evaluated against tenant rules. └── Outcome: Dispatched successfully. ``` ### Key Behavioral Rules in This Scenario 1. **`STOP` writes scope `all`**: When the recipient sent `STOP`, Orbit stamped suppression across all channels for that phone number (SMS, WhatsApp, voice). Even if the user only intended to stop promotional SMS, the platform adheres to TCPA revocation parity: a phone-level stop fences the device. 2. **`START` unblocks suppression**: The inbound `START` keyword clears the active suppression row written by the previous opt-out and appends a fresh `opted_in` audit record. Historical revocation records are never deleted; a new grant is appended. 3. **Transactional gating**: Does marketing consent gate transactional messages? No. When `exempt_transactional` is enabled (the default setting in Orbit preflight), transactional messages rely on contractual necessity or legitimate interest rather than marketing consent. However, if the recipient remained in active `STOP` suppression, even transactional sends would be blocked by the transport firewall until unsuppressed. *** ## 4. Role Mapping: Consent-First Architecture vs Inbound Suppression Architecting a compliant messaging operation requires separating the responsibilities of affirmative consent management from defensive suppression handling: ``` +---------------------------------------------------------------------------------------+ | OUTBOUND PIPELINE | | | | +-----------------------+ +-----------------------+ +-----------------+ | | | 1. Suppression Fence | ---> | 2. Consent Gate | ---> | 3. Dispatch | | | | (Defensive Drop) | | (Affirmative Opt-In) | | (Quiet Hours & | | | | Check: suppression | | Check: consent_record | | Country Gates) | | | +-----------------------+ +-----------------------+ +-----------------+ | | ^ ^ | +--------------|------------------------------|-----------------------------------------+ | | +--------------|------------+ +-------------|-----------------------------------------+ | INBOUND SUPPRESSION | | CONSENT-FIRST ARCHITECTURE | | | | | | • Handles STOP / CANCEL | | • Handles web signup forms & double opt-in handshakes | | • Writes scope='all' | | • Scoped to specific channels and purposes | | • Immediate drop filter | | • Tracks legal basis (GDPR Art 6, TCPA, DPDP) | | • Zero marketing leeway | | • Evaluates validity_until expiration windows | +---------------------------+ +-------------------------------------------------------+ ``` ### Inbound Suppression (Defensive Layer) * **Purpose**: Defensive compliance enforcement protecting recipients from unwanted contact after revocation. * **Trigger Mechanism**: Inbound keyword replies (`STOP`, `END`, `QUIT`), manual CSV bulk suppression imports, or API revocations (`opt_in: false`). * **Enforcement Behavior**: Acts as a hard firewall at the entry point of the send service. If an identifier matches an active suppression row for the given channel or `all`, the pipeline drops the request before queuing or billing. * **Scope**: Default `all` across all messaging and voice capabilities linked to that phone number. ### Consent-First Architecture (Affirmative Layer) * **Purpose**: Lifecycle tracking of affirmative permissions granted by data subjects for specific communication categories (e.g., promotional newsletters, product alerts, automated agent outreach). * **Trigger Mechanism**: Web forms, double opt-in confirmation handshakes (`POST /compliance/consent/double-opt-in`), paper agreements, or signed digital receipts. * **Enforcement Behavior**: Evaluated downstream from the suppression check. Verifies whether an active, non-expired grant exists under `consent_records` before permitting marketing traffic. * **Scope**: Granular per channel (`sms`, `whatsapp`, `email`, `voice`) and per purpose (`marketing`, `transactional`). By maintaining suppression as a platform-wide defensive fence and consent as an application-level affirmative filter, operators ensure both strict regulatory adherence (preventing unauthorized outreach) and flexible communication delivery (enabling critical transactional notifications). *** ## Related Guides * [Opt-Out Keyword Alias Table](/compliance/opt-out-keyword-alias-table) — Seeded multi-lingual STOP and START keyword vocabularies and scope propagation rules. * [Consent Management & Receipts](/compliance/consent-management) — Recording affirmative grants, revocation flows, expiry windows, and signed DPDP receipts. * [Opt-Out & Suppression Lists](/compliance/opt-out-suppression) — Bulk suppression import workflows, deduplication rules, and ledger exports. * [Send Gates & Quiet Hours](/compliance/send-gates) — Pre-flight timing windows, BAA requirements, and carrier pre-flight linters. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.