> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ouraicalling.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Einwilligung & Compliance

> Universelle oder kanalbezogene Opt-outs konfigurieren und kanalübergreifende Suppressions verwalten.

Einwilligung & Compliance steuert, wie **Marketing-Opt-outs** in einem
Workspace durchgesetzt werden. Die Suppression ist immer aktiv.
Workspace-Owner und -Admins konfigurieren den Modus unter
**Einstellungen → Daten → Suppression**; andere Mitglieder haben
schreibgeschützten Zugriff.

## Einwilligungsmodi

### Universelle Abmeldung

Ein Opt-out über einen beliebigen Kanal erzeugt den Scope `all`. Der verknüpfte
Kontakt wird für Marketing-Kommunikation über Voice, SMS, E-Mail und
unterstützte Messaging-Kanäle gesperrt.

Der universelle Modus ist die konservative Standardeinstellung und steht in
jedem Plan zur Verfügung.

### Abmeldung pro Kanal

Ein Opt-out gilt nur für den Ursprungskanal. Eine SMS-Abmeldung blockiert
beispielsweise SMS-Marketing, während eine eigenständige Einwilligung für Voice
oder E-Mail weiterhin nutzbar sein kann.

Der kanalbezogene Modus benötigt das Plan-Feature **Consent & Compliance**.
Steht es nicht zur Verfügung, bleibt der Workspace im universellen Modus; die
Durchsetzung von Suppressions wird niemals deaktiviert.

<Note>
  Eine Änderung des Workspace-Modus schreibt bestehende Suppressions nicht
  stillschweigend um. Jeder Eintrag behält seinen `scope` und
  `mode_at_opt_out`, sodass die beim Opt-out angewandte Regel auditierbar bleibt.
</Note>

## Suppressions-Einträge

Ein aktiver Eintrag kann mit einer Kontakt-ID, Telefonnummer oder E-Mail-Adresse
verknüpft sein. Er enthält:

* `scope`: `all` oder den betroffenen Kanal;
* `origin_channel`: den Ursprung des Opt-outs;
* `purpose`: aktuell `marketing`;
* `source`, `reason` und Erstellungszeitpunkt;
* `mode_at_opt_out`: den beim Opt-out aktiven Workspace-Modus.

Eine Liste mit `channel`-Filter enthält sowohl Einträge für diesen Kanal als
auch universelle (`all`) Einträge, da beide die Kontaktaufnahme über den
angefragten Kanal blockieren.

## Einwilligung wiederherstellen

Die Wiederherstellung löscht den Compliance-Verlauf nicht. Die aktive
Suppression wird widerrufen und ein Opt-in-Event an den Audit-Trail angehängt.

Verwende möglichst die UUID des Suppressions-Eintrags. Eine URL-codierte
E.164-Nummer oder E-Mail-Adresse wird ebenfalls akzeptiert; bei mehreren
kanalbezogenen Einträgen eines Kontakts ist die UUID jedoch eindeutig.

<Warning>
  Stelle eine Einwilligung nur wieder her, wenn dafür eine angemessene,
  dokumentierte Grundlage vorliegt. Produkteinstellungen unterstützen die
  Durchsetzung, ersetzen aber keine rechtliche Prüfung für Rechtsraum, Zweck und
  Kommunikationskanal.
</Warning>

## REST API

Workspace-Modus lesen oder ändern:

```bash theme={null}
curl https://YOUR_DOMAIN/api/v1/settings/consent-compliance \
  -H "Authorization: Bearer fam_..."
```

```bash theme={null}
curl -X PATCH https://YOUR_DOMAIN/api/v1/settings/consent-compliance \
  -H "Authorization: Bearer fam_..." \
  -H "Content-Type: application/json" \
  -d '{"mode":"per_channel"}'
```

Opt-out erfassen:

```bash theme={null}
curl -X POST https://YOUR_DOMAIN/api/v1/suppression-list \
  -H "Authorization: Bearer fam_..." \
  -H "Content-Type: application/json" \
  -d '{
    "email": "kontakt@example.com",
    "channel": "email",
    "reason": "Abmeldung angefordert"
  }'
```

Die Suppression-API erwartet mindestens `contact_id`, `phone` oder `email`.
Fehlt `channel`, wird bei einer Telefonnummer `voice` und bei einer
E-Mail-Adresse `email` verwendet. Mit
`GET /api/v1/suppression-list?channel=sms` werden Einträge aufgelistet, die SMS
blockieren. Ein einzelner Eintrag wird mit
`DELETE /api/v1/suppression-list/{id-or-identity}` wiederhergestellt.

REST-Scopes sind `settings:read` / `settings:write` für den Modus und
`suppression:read` / `suppression:write` für Einträge.

## MCP

* `get_consent_mode` und `set_consent_mode`;
* `list_suppression_entries`;
* `add_suppression_entry`;
* `remove_suppression_entry` (stellt Consent wieder her und behält den
  Audit-Trail).

Alle MCP-Ergebnisse verwenden denselben Public-Payload-Sanitizer wie die REST
API.