
Ü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ützendebreaches[]-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).
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.
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.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 }.statusistSuccess,RetryoderUndeliverable;reasonistnull, es sei denn, der Versand ist fehlgeschlagen (email_can_not_be_deliveredoderunknownfür nicht erkannte Legacy-Werte). - Prüfereignisse (
VALID_CODE_ENTERED,INVALID_CODE_ENTERED) —{ code_tried, status }mitstatusApproved,Failed,Expired or Not FoundoderDeclined. - Ereignisse zum finalen Status —
null, außerEMAIL_VERIFICATION_DECLINED/EMAIL_VERIFICATION_IN_REVIEW, die{ "reason": "<risk code>" }enthalten (z. B.UNDELIVERABLE_EMAIL_DETECTED).
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 alsDeclined 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 Stufeinformation, da disposable_email_action auf dem Standardwert NO_ACTION belassen wurde.
Verwandte Themen
- Übersicht über die E-Mail-Verifizierung — Funktionsweise und Preise.
- Warnungen der E-Mail-Verifizierung — alle Risikocodes, Ablehnungsauslöser und konfigurierbare Aktionen.
- Datenmodelle — E-Mail-Verifizierung — kanonisches Feld-für-Feld-Schema.
- E-Mail-API — OTP senden und OTP prüfen — eigenständige Server-zu-Server-Endpoints.
- Management-API — Listen — verwalten Sie die E-Mail-Sperrliste, die
matches[]mitsource: list_entryspeist.