Zum Hauptinhalt springen
Der Bericht zur E-Mail-Verifizierung erfasst das vollständige Ergebnis einer E-Mail-OTP-Abfrage: an wen die Nachricht gesendet wurde, ob die Adresse eine Wegwerfadresse oder unzustellbar ist, ob sie in bekannten Datenlecks auftaucht, wie viele Versuche der Benutzer unternommen hat, sowie alle sitzungsübergreifenden Übereinstimmungen mit Ihrer Sperrliste oder anderen genehmigten Benutzern. Diese Seite dokumentiert die JSON-Struktur, die vom Entscheidungs-Endpoint zurückgegeben wird, damit Sie OTP-Ergebnisse, die Gefährdung durch Datenlecks und Risiko-Flags für jede verifizierte Adresse verarbeiten können.
Didit-E-Mail-Verifizierungsbericht mit OTP-Ergebnis, Datenleck-Daten und Risiko-Flags

Übersicht

Ein E-Mail-Bericht wird jedes Mal erstellt, wenn ein Workflow-Knoten die Funktion zur E-Mail-Verifizierung ausführt. Jeder Bericht stellt eine OTP-Abfrage für eine Adresse dar und enthält:
  • Die verifizierte email-Adresse.
  • Boolesche Risiko-Flags (is_breached, is_disposable, is_undeliverable) und das unterstützende breaches[]-Array aus einer Datenbank für Informationen zu Datenlecks.
  • Die Anzahl der OTP-Sendeversuche (verification_attempts) und den Zeitstempel der Genehmigung.
  • Ein chronologisches lifecycle[]-Protokoll aller Sende-, Wiederholungs- und Code-Überprüfungsversuche.
  • Ein matches[]-Array, das dieselbe Adresse bei anderen genehmigten E-Mail-Verifizierungen oder auf Ihrer Sperrliste anzeigt.
  • Ein warnings[]-Array – Risikoereignisse, die während der Verifizierung ausgegeben wurden (siehe Warnungen zur E-Mail-Verifizierung).
  • Eine node_id, die identifiziert, welcher Workflow-Graph-Knoten den Bericht erstellt hat (nur V3-Sitzungen).
In gehosteten Workflow-Sitzungen läuft die OTP-Abfrage innerhalb der Didit-Verifizierungs-UI ab – Sie lesen das Ergebnis lediglich aus der Entscheidungs-Payload ab. Für Server-zu-Server-OTP ohne gehosteten Ablauf verwenden Sie die eigenständige E-Mail-API: POST /v3/email/send/ stellt den Code zu und POST /v3/email/check/ validiert die Eingabe des Benutzers; abgeschlossene eigenständige Verifizierungen werden über dasselbe Berichtsformat bereitgestellt. Gehostete Sitzungen begrenzen den Benutzer standardmäßig auf 2 falsche Code-Eingaben (email_max_check_attempts) und 2 OTP-Sendungen – die anfängliche Sendung plus ein erneuter Versand (email_max_retries), für jeden Workflow-Knoten anpassbar. Das Überschreiten eines dieser Limits schließt den Schritt als Declined mit EMAIL_CODE_ATTEMPTS_EXCEEDED ab.

Wo es in API-Antworten vorkommt

Der Entscheidungs-Endpoint (GET /v3/session/{sessionId}/decision/) gibt E-Mail-Berichte unter dem Array-Schlüssel im Plural email_verifications zurück. Das Array enthält einen Eintrag pro E-Mail-Verifizierungs-Knoten im Workflow-Graphen – typischerweise einen, aber Step-up-Abläufe können mehrere erzeugen.
Ein null-Wert bedeutet, dass noch kein E-Mail-Verifizierungsschritt ausgeführt wurde. Iterieren Sie über das Array (anstatt nur email_verifications[0] auszulesen), wenn Ihr Workflow mehr als eine E-Mail-Adresse erfassen kann.

Schema

Das kanonische Feld-für-Feld-Schema befindet sich auf der Seite Datenmodelle.
Eine unzustellbare Adresse — ungültige Syntax, eine nicht existente Domain, fehlende MX-Einträge oder eine fehlgeschlagene OTP-Zustellung — schließt den Schritt als Declined mit der automatischen Ablehnungswarnung UNDELIVERABLE_EMAIL_DETECTED ab. Die einzige Ausnahme: Wenn der Benutzer die Adresse selbst eingegeben hat (sie wurde bei der Sitzungserstellung nicht vorausgefüllt), gibt ein unzustellbarer Versand einen Inline-Fehler zurück, sodass er es mit einer anderen Adresse erneut versuchen kann, anstatt sofort abgelehnt zu werden.

Statuswerte

Lifecycle-Ereignistypen

lifecycle[] ist chronologisch sortiert. Jedes Ereignis hat type, timestamp, details und eine abrechenbare fee (sofern zutreffend): Die details-Payload hängt von der Ereignisfamilie ab:
  • Sendeereignisse (EMAIL_VERIFICATION_MESSAGE_SENT, EMAIL_VERIFICATION_RETRY_MESSAGE_SENT) — { status, reason }. status ist Success, Retry oder Undeliverable; reason ist null, es sei denn, der Versand ist fehlgeschlagen (email_can_not_be_delivered oder unknown für nicht erkannte Legacy-Werte).
  • Prüfereignisse (VALID_CODE_ENTERED, INVALID_CODE_ENTERED) — { code_tried, status } mit status Approved, Failed, Expired or Not Found oder Declined.
  • Ereignisse zum finalen Status — null, außer EMAIL_VERIFICATION_DECLINED / EMAIL_VERIFICATION_IN_REVIEW, die { "reason": "<risk code>" } enthalten (z. B. UNDELIVERABLE_EMAIL_DETECTED).
Sendungen mit status Success oder Undeliverable erfassen die E-Mail-Verifizierungsgebühr von $0.02; Retry-Sendungen, Prüfereignisse und Statusereignisse enthalten immer fee: 0.

Sitzungsübergreifende Übereinstimmungen

matches[] erfasst dieselbe Adresse bei zuvor genehmigten E-Mail-Verifizierungen in derselben Anwendung — über KYC-, KYB- und Standalone-API-Sitzungen hinweg — sowie Sperrlisten-Treffer, die in den Management-API-Listen konfiguriert sind. Verifizierungen, die die vendor_data der aktuellen Sitzung teilen, werden ausgeschlossen (derselbe Endbenutzer stimmt nicht mit sich selbst überein); das Array ist auf 5 Einträge begrenzt, sortiert von alt nach neu. Wenn sich die Adresse auf Ihrer Sperrliste befindet, aber keine der übereinstimmenden Sitzungen auf der Sperrliste steht, wird dem Array ein synthetischer Eintrag mit source: "list_entry" (alle Sitzungsfelder null) vorangestellt.

Beispiele

Genehmigt — sauberes OTP mit einer Informationswarnung

Abgelehnt — unzustellbare Adresse

Eine vorausgefüllte Adresse, die die Syntax- oder DNS-/MX-Validierung nicht besteht — oder deren OTP-E-Mail nicht zugestellt werden kann —, wird sofort als Declined abgeschlossen. Es erscheinen keine Code-Prüfereignisse, da den Benutzer nie ein Code erreicht hat.

Abgelehnt — gesperrte Wegwerf-Mailbox

Der Benutzer hat die OTP-Verifizierung abgeschlossen, aber die Adresse stimmte mit Ihrer E-Mail-Sperrliste überein (automatische Ablehnung). Das Wegwerf-Flag wird ebenfalls gesetzt — hier auf der Stufe information, da disposable_email_action auf dem Standardwert NO_ACTION belassen wurde.

Verwandte Themen

Zuletzt geändert am 7. November 2026