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

# Reconcile suppression across email and phone

> Understand how address-level suppression and channel scope work when a contact has both an email address and a phone number, then reconcile opt-outs through the Consent API, CSV import, or contact merge.

# Reconcile suppression across email and phone

A contact record can hold several ways to reach the same person. The suppression ledger still evaluates the address and scope on each entry; it does not infer that an opt-out for one address applies to every other address on the contact. Use this guide when reconciling an email address and a phone number, including WhatsApp ID, after a contact merge or consent update.

<Note>
  Suppression scope and lawful basis are tenant-owned decisions. Orbit records and enforces the controls you choose; it does not decide whether an opt-out should extend to another address. Confirm the policy that fits your use case with counsel.
</Note>

## The double-address problem

An email entry blocks email sends to that email address. An E.164 phone entry with scope `all` blocks phone-based SMS, voice, and WhatsApp sends to that number. A WhatsApp ID row is also phone-based and should use `all` when the signal applies to every channel reachable on that identifier.

The Preference Center presents the configured per-channel choices for the address associated with the signed link. Opting out of email changes the email preference; it does not silently opt the phone number out. A contact's other address is not automatically suppressed, even if both addresses appear on one contact record. This separation is intentional: the recipient may have a different permission or relationship on each address.

Treat the ledger as address-level evidence, not as a single contact-level flag. A phone row cannot block an email address it does not contain, and an email row cannot block calls or messages to a phone number. For scope meanings and CSV defaults, see [Opt-Out & Suppression Lists](/compliance/opt-out-suppression).

## Reconciliation patterns

Choose the operation that matches the event and the evidence you hold:

* **Consent API — extend one revocation across known addresses.** For a contact-level revocation that your tenant policy applies to every known address, submit one Consent API revocation event listing all current identifiers for that contact, including each email and E.164 phone or WhatsApp ID. Include the channels and event details required by your Consent API request schema. Do not submit only the address that happened to receive the signal when your decision covers the whole contact. See [Consent Management](/compliance/consent-management) for the endpoint contract.
* **Bulk CSV — import each address as its own row.** Set `channel=all` on phone and `wa_id` rows when the suppression applies to every channel reachable on that identifier. Set `channel=email` on email rows. The address-type defaults are the same when no `channel` column is supplied, but explicit values make a reconciliation file easier to audit. A row carrying both a phone and email shares one scope across both addresses, so use separate rows when their scopes differ.

  ```csv theme={null}
  phone,email,wa_id,channel,reason
  +14155550101,,,all,contact-level opt-out
  ,jordan@example.com,,email,contact-level opt-out
  ```

  Import the file through `POST /compliance/suppression-list/import`. Preview with `dry_run=true` before writing, then check the per-row results and export the active ledger to confirm both addresses landed with the intended scopes.
* **Contact merge — reconcile during identity cleanup.** When you merge duplicate contact records, review the active suppression entries associated with both records and compare them with the merged record's known addresses. A merge can bring identifiers together in your contact view; it does not itself mean that an address-specific suppression should be copied to every other address. Use the [contact merge surface](/guides/contact-merge) to perform the merge, then use your tenant's chosen consent or import path to add any missing address-level entries.

For a multi-address contact, reconcile by identifier and scope together. In the CSV convention above, the phone row's `all` covers phone-based channels; the separate email row blocks the email address. `all` on a phone row does not reach a different email address.

## Why suppression does not automatically extend

An opt-out is evidence about the address and purpose named by the event. Automatically copying it to every address on a contact could remove someone from a channel where they still have a legitimate interest or a separate permission. Orbit therefore does not infer cross-address intent from a shared contact record.

Your tenant owns the scope decision. Use the closest-fit lawful basis for the event and purpose, keep the source and timing in your consent records, and extend a block only when your policy and the recipient's signal support it. This guide is operational information, not legal advice.

## Three worked examples

### 1. Email spam complaint; phone remains available

Jordan reports a marketing email as spam. Your email process records a suppression for `jordan@example.com` with scope `email`. Jordan's phone, `+14155550101`, remains unchanged: the email complaint did not itself suppress SMS, voice, or WhatsApp on that number. If your tenant policy treats the complaint as a contact-wide opt-out, explicitly extend the revocation to the phone address through the Consent API or a separate CSV row; do not assume the email entry did that.

### 2. SMS STOP; extend the decision to the known email

Jordan texts `STOP` from `+14155550101`. The phone entry uses scope `all`, which blocks SMS, voice, and WhatsApp on that number. If the event and your tenant policy also mean Jordan should no longer receive email, record a separate email-address suppression as part of the same contact-level reconciliation. With CSV, use a phone row with `channel=all` and an email row with `channel=email`; with the Consent API, list both known identifiers in the revocation event supported by your request schema. The email is blocked by its own ledger entry, not because the phone's `all` scope spans a different address.

### 3. Preference Center email link; only the email is opted out

Jordan clicks the Preference Center link in an email and turns off email while leaving SMS enabled. The email address is suppressed for email, while the phone remains opted in. The signed link lets the page apply the selected preferences to the associated contact; it does not turn an email-channel choice into an opt-out for the contact's other address. If Jordan later asks to stop all contact, reconcile the phone separately.

## Tenant-owned scope decisions

Before adding or changing entries, decide whether the event applies to one address, every channel reachable on that address, or all known addresses for the contact. Preserve that distinction in your records:

| Decision | Address entries to reconcile | Scope |
| - | - | - |
| Email-only opt-out | The email address | `email` |
| Phone/WhatsApp opt-out | The E.164 phone or `wa_id` | `all` for phone-based channels |
| Contact-wide opt-out covering both | Each known address, separately | `all` for phone/`wa_id`; `email` for email CSV rows |

After an import or merge, export the active suppression ledger and verify each address and scope. Keep the consent history alongside that export when you need to understand why an entry exists.

## Related guides

* [Opt-Out & Suppression Lists](/compliance/opt-out-suppression) — channel scopes, CSV format, import, and export.
* [Choose your suppression entry point](/guides/suppression-three-entry-points) — compare CSV, Consent API, and Preference Center inputs.
* [Preference center: the public opt-in/opt-out page](/guides/preference-center-opt-out-page) — configure the hosted page and understand its channel choices.
* [Contact merge](/guides/contact-merge) — merge duplicate contact records.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.