Skip to main content

Preference Center: die öffentliche Opt-in/Opt-out-Seite

Englisches Original: Preference center: the public opt-in/opt-out page.
Das Preference Center ist eine öffentliche Seite, auf der ein Kontakt seine eigenen Kanal-Opt-ins, Abonnement-Themen, Nachrichtenfrequenz und (falls Sie es aktivieren) einen Datenlösch-Antrag verwaltet — ohne Konto, ohne Login. Jeder Kontakt erreicht sie über einen signierten Link: Die URL trägt ein HMAC-SHA256-Token (v1.<payload>.<signature>), das nach 30 Tagen abläuft, sodass die Seite self-service bleibt und dennoch auf genau einen Kontakt in genau einer Organisation beschränkt ist. Die zusammengefasste Endpunkt-Oberfläche lebt außerdem in Send Gates; dieser Guide ist der volle Walkthrough: jedes Konfigurationsfeld, wohin der Link gehört, was die API der öffentlichen Seite zurückgibt und welche Compliance-Oberflächen ein Opt-out oder Opt-in schreibt. Alle Endpunkte unten haben ihren Root unter https://api.orbit.devotel.io/api/v1/compliance.
Das Preference Center ist ein Tenant-eigenes Control: Sie wählen Kanäle, Themen und Branding, und Ihre Organisation hält die Einwilligungs-Nachweise. Orbit betreibt die Plattform; die Einwilligungsentscheidung gehört dem Kontakt. Dieser Guide ist keine Rechtsberatung — klären Sie Ihre Pflichten mit anwaltlichem Rat.

1. Einmal konfigurieren: POST/GET /preference-center

Setzen Sie die Konfiguration mit POST /preference-center (Owner/Admin-API-Key). Der Endpunkt upsertet die Konfiguration in die Einstellungen Ihrer Organisation und gibt das gespeicherte Objekt zurück — erneut ausführen, um zu aktualisieren. GET /preference-center liest die aktuelle Konfiguration zurück; vor der Konfiguration liefert es enabled: false mit einem Hinweis.

Konfigurationsfelder

Jedes Feld wird serverseitig validiert — ein abgelehnter POST liefert 422 mit Feld-Einzelmeldungen (field, message), damit Sie erkennen, welches Feld fehlgeschlagen ist.

Abonnement-Themen

Ein Thema ist eine benannte Gruppe — Newsletter, Product Updates, Billing Alerts —, in die ein Kontakt sich ein- oder austritt, ohne den ganzen Kanal anzutasten. Themen-ids müssen eindeutig sein und dem Slug-Muster entsprechen ([a-z0-9][a-z0-9_-]{0,63}); jeder Eintrag hat:
  • name (1–120 Zeichen) — der Anzeigename auf der Seite.
  • description (optional, ≤500) — eine Kontextzeile neben der Kachel.
  • defaultOptIn (Standard false) — wie ein Kontakt ohne erfasste Präferenz behandelt wird.
  • archived (optional) — archivierte Themen bleiben im Audit-Trail, rendern aber nicht mehr auf der Seite.
Lint-Fettnäpfchen: URLs, die die http(s)-Schema-Verfeinerung nicht bestehen, werden vorab abgelehnt, und doppelte Themen-ids scheitern mit “Topic ids must be unique”, statt still überschrieben zu werden.
Nach der Konfiguration erzeugen Sie Links für je einen Kontakt mit POST /preference-center/link:
Die Antwort liefert link — eine URL der Form ${DEVOTEL_WEB_URL}/preferences?token=v1…. Punkte zur Beachtung:
  • Der Link zielt auf die gehostete Seite, nicht auf den JSON-Endpunkt. Kopieren Sie ihn wortwörtlich in Ihre Footer-/Sender-Templates; die Seite selbst holt den Daten-Endpunkt unter der Haube.
  • 30 Tage TTL. Danach verifiziert das Token als abgelaufen, und der Kontakt muss einen frischen Link anfordern (einen neuen zu prägen kostet einen API-Aufruf).
  • Die Seite ist zur Prägezeit Locale-agnostisch. Die Web-App löst einen Redirect unter Beibehaltung der ?token=-Query auf, Sie müssen also das Locale des Kontakts nicht raten.

Wohin damit

  • Marketing-Sendungen mit Freitext-Body: wird für Sie angehängt. Sie müssen den Link nicht platzieren. Orbit hängt während aktivem Preference Center an jede Marketing-Sendung mit Freitext-Body eine Zeile {optOutMessage}: {link} an — auf sms und whatsapp über Ihre gebrandete Kurzdomain, auf email und den übrigen Freitext-Kanälen als rohen tokenisierten Link — und Template-Sendungen werden übersprungen. Dieselbe Seite beschreibt, wann der Footer erscheint, was der angehängte Klick schreibt und wie er sich zur Carrier-Formulierung “Reply STOP” verhält: siehe Preference Center: when Orbit appends the opt-out footer for you.
  • Transaktionale und Template-Sendungen: selbst platzieren. Diese Sendungen tragen den angehängten Footer nie, daher ist der oben geprägte Link ihr Weg zum Ein-Klick-Abmelden: kopieren Sie ihn wortwörtlich in den Abmeldebereich Ihrer E-Mail-Templates und dichten Sie ihn in Template-Texte oder transaktionale Bodys ein, wo Sie einen wollen. Für eine Platzierung einen kurzen getrackten Link zu prägen ist optional; schlägt die Kurzlink-Prägung fehl, funktioniert weiterhin der rohe Link — der Fallback ist additiv, nie tragend für Compliance.
  • Suppressions-getriebenes Re-Opt-in. Wenn ein Kontakt durch einen anderen Flow wieder eintritt, können Sie ihm einen frischen Link geben, damit er dieselbe Self-Service-Seite erhält.

3. Die öffentliche Token-Seite

Die gehostete Seite liest und schreibt über zwei unauthentifizierte Endpunkte, die vom signierten Token gated werden:
  • GET /preferences/:token — liefert das Seiten-Payload.
  • PUT /preferences/:token — wendet Updates an.
Ungültige Token-Formen liefern 400 INVALID_TOKEN; abgelaufene oder manipulierte Token liefern 401 TOKEN_EXPIRED mit “Please request a new link.”

GET-Antwort

Das Payload bündelt den aktuellen Zustand des Kontakts und die Org-Konfiguration:
E-Mail und Telefon sind in der öffentlichen Antwort maskiert — die Seite zeigt nie den rohen Identifikator, mit dem sie aufgerufen wird. consentHistory ist der Audit-Trail der Opt-ins/Opt-outs des Kontakts, neueste zuerst, gekappt auf 20 Zeilen, gespeist aus demselben Consent-Ledger, das Ihre Operatoren im Dashboard sehen.

PUT-Request-Body

  • channelPreferences — partielle Map erlaubt (Zod partial-record); mindestens ein Kanal ist erforderlich.
  • frequencyPreference — optional, eines von all, important_only, weekly_digest, monthly_digest.
  • topicPreferences — optionale { topicId: opted_in | opted_out }-Map, validiert gegen Ihre konfigurierten Themen; unbekannte Ids werden ignoriert.
  • requestDataDeletion — setzt einen GDPR-Löschantrag parallel zum Opt-out (siehe Abschnitt 6).
Eine 422-Antwort trägt Feld-Einzelmeldungen, damit das gehostete Formular auf die ungültige Wahl zeigen kann.

4. Wie Updates fließen

Ein hier geschriebenes Opt-in/Opt-out ist nicht nur ein UI-Flag — dieselben vier Compliance-Oberflächen, die ein STOP-Keyword schreibt, werden aktualisiert:
  • Consent-Ledger. Pro Kanal (oder pro Thema) wird eine consent_records-Zeile mit source: preference_center angehängt — Ihr GDPR-Art-7-Beweislast-Audit-Trail.
  • Suppression-Liste. Auf jedem abgemeldeten Kanal wird die kanonisierte Telefonnummer/E-Mail des Kontakts mit Scope all eingefügt — eine kanalübergreifende Sperre, die jedes Send-Gate liest.
  • STOP-Zaun. Ein Redis-Fast-Path-Zaun wird bei Opt-out gesetzt (und bei vollständigem Re-Opt-in gelöscht), sodass laufende Kampagnen-Batches die Änderung sehen, bevor die langsamere Datenbank-Suppression propagiert.
  • Audit-Log. compliance.preference_center_updated wird aufgezeichnet, wenn Sie die Konfiguration ändern, und Kontakt-Level-Opt-in/out-Ereignisse werden im Consent-Ledger erfasst.
Re-Opt-in symmetrisch: ein volles Opt-in (jeder Kanal opted_in) widerruft aktive Suppression-Zeilen für Telefon und E-Mail des Kontakts und löscht den STOP-Zaun, während das Consent-Ledger den umgekehrten Eintrag erhält.
Thema vs. Kanal. Ein Opt-out auf Kanalebene gewinnt immer — eine Themen-Kachel verengt die Einwilligung innerhalb der Kanäle, die der Kontakt weiterhin akzeptiert. Unbekannte Themen-Ids in einem PUT werden ignoriert statt persistiert, sodass ein veraltetes Formular keine beliebigen Attributschlüssel schreiben kann.

5. Semantik der GDPR-Lösch-Kachel

Wenn showGdprDelete aktiviert ist und der Kontakt im PUT requestDataDeletion: true setzt, zeichnet die API einen Legacy-GDPR-Löschantrag auf — eine pending-Zeile, markiert für Ihren Datenlöschprozess — parallel zum Opt-out. Diese Markierung ist bewusst: Die Lösch-Kachel des Preference Centers markiert den Kontakt, sie startet nicht die getrackte DSAR-Pipeline.
Die Lösch-Kachel des Preference Centers hat keine SLA-Uhr, keinen entschlüsselten Datenexport und kein Article-17-Löschzertifikat. Einen Right-to-Erasure-Antrag, den Ihr DPO tracken kann, reichen Sie über den DSAR-Endpunkt ein (POST /compliance/dsar, Owner/Admin) — siehe Data Subject Access Requests und den DSAR + Breach-Register-Guide.

6. Testen

Zwei ausgearbeitete curl-Beispiele, die Sie in ein Smoke-Script kleben können: Konfiguration speichern:
Erwartet: 201 mit der gespeicherten Konfiguration als Echo. Link prägen und die öffentlichen Endpunkte ausüben:
Erwartet: Der GET liefert die aktuellen Präferenzen des Kontakts; der PUT liefert updated: true plus die angewandten Präferenzen und, falls angefordert, einen gdprRequest-Eintrag. Häufige Fehler zum Abprüfen: 400 INVALID_TOKEN (fehlgeformtes Token), 401 TOKEN_EXPIRED (TTL verstrichen oder Signatur-Mismatch — neuen Link prägen), 422 VALIDATION_ERROR (feldbezogene Meldungen im Konfigurations- oder Update-Body) und 404 NOT_FOUND, wenn das Preference Center deaktiviert ist oder die Kontakt-Id nicht existiert.