मुख्य सामग्री पर जाएं
ईमेल सत्यापन रिपोर्ट ईमेल OTP चैलेंज का पूरा परिणाम कैप्चर करती है: संदेश किसे भेजा गया था, क्या पता डिस्पोज़ेबल या अनडिलीवरेबल है, क्या यह ज्ञात डेटा ब्रीच में दिखाई देता है, उपयोगकर्ता ने कितने प्रयास किए, और आपकी ब्लॉकलिस्ट या अन्य स्वीकृत उपयोगकर्ताओं के साथ कोई क्रॉस-सत्र मिलान। यह पेज निर्णय endpoint द्वारा लौटाए गए JSON प्रारूप का दस्तावेज़ीकरण करता है ताकि आप प्रत्येक सत्यापित पते के लिए OTP परिणाम, ब्रीच एक्सपोज़र और जोखिम फ़्लैग को पार्स कर सकें।
OTP परिणाम, ब्रीच डेटा और जोखिम फ़्लैग दिखाने वाली Didit ईमेल सत्यापन रिपोर्ट

अवलोकन

हर बार जब कोई वर्कफ़्लो नोड ईमेल सत्यापन सुविधा चलाता है, तो एक ईमेल रिपोर्ट जनरेट होती है। प्रत्येक रिपोर्ट एक पते के विरुद्ध एक OTP चैलेंज का प्रतिनिधित्व करती है और इसमें शामिल हैं:
  • सत्यापित email पता।
  • बूलियन जोखिम फ़्लैग (is_breached, is_disposable, is_undeliverable) और ब्रीच-इंटेलिजेंस डेटाबेस से प्राप्त सहायक breaches[] ऐरे।
  • OTP भेजने के प्रयासों की संख्या (verification_attempts) और स्वीकृति टाइमस्टैम्प।
  • हर बार भेजने, पुनः प्रयास करने और कोड जाँचने का एक कालानुक्रमिक lifecycle[] लॉग।
  • अन्य स्वीकृत ईमेल सत्यापनों या आपकी ब्लॉकलिस्ट पर समान पते को सामने लाने वाला एक matches[] ऐरे।
  • एक warnings[] ऐरे — सत्यापन के दौरान उत्पन्न जोखिम इवेंट (देखें ईमेल सत्यापन चेतावनियाँ)।
  • एक node_id जो पहचानता है कि किस वर्कफ़्लो ग्राफ़ नोड ने रिपोर्ट जनरेट की (केवल V3 सत्र)।
होस्टेड वर्कफ़्लो सत्रों में OTP चैलेंज Didit सत्यापन UI के अंदर चलता है — आप केवल निर्णय payload से परिणाम पढ़ते हैं। बिना होस्टेड फ़्लो के सर्वर-टू-सर्वर OTP के लिए, स्टैंडअलोन Email API का उपयोग करें: POST /v3/email/send/ कोड डिलीवर करता है और POST /v3/email/check/ उपयोगकर्ता की प्रविष्टि को मान्य करता है; फ़ाइनलाइज़ किए गए स्टैंडअलोन सत्यापन उसी रिपोर्ट प्रारूप के माध्यम से सामने आते हैं। होस्टेड सत्र डिफ़ॉल्ट रूप से उपयोगकर्ता को 2 गलत कोड प्रविष्टियों (email_max_check_attempts) और 2 OTP भेजने — प्रारंभिक भेजने के साथ एक पुनः भेजने (email_max_retries) तक सीमित करते हैं, जिसे प्रति वर्कफ़्लो नोड ट्यून किया जा सकता है। किसी भी सीमा को पार करने पर चरण को EMAIL_CODE_ATTEMPTS_EXCEEDED के साथ Declined के रूप में फ़ाइनलाइज़ किया जाता है।

यह API रिस्पॉन्स में कहाँ दिखाई देता है

निर्णय endpoint (GET /v3/session/{sessionId}/decision/) बहुवचन ऐरे कुंजी email_verifications के तहत ईमेल रिपोर्ट लौटाता है। ऐरे में वर्कफ़्लो ग्राफ़ में प्रति ईमेल सत्यापन नोड एक प्रविष्टि होती है — आमतौर पर एक, लेकिन स्टेप-अप फ़्लो कई प्रविष्टियाँ उत्पन्न कर सकते हैं।
null मान का अर्थ है कि अभी तक कोई ईमेल सत्यापन चरण नहीं चला है। जब आपका वर्कफ़्लो एक से अधिक ईमेल पते एकत्र कर सकता है, तो ऐरे पर पुनरावृति करें (email_verifications[0] पढ़ने के बजाय)।

स्कीमा

फ़ील्ड-दर-फ़ील्ड कैनोनिकल स्कीमा डेटा मॉडल पेज पर मौजूद है।
एक ऐसा पता जिस पर डिलीवरी संभव न हो — अमान्य सिंटैक्स, अस्तित्वहीन डोमेन, अनुपलब्ध MX रिकॉर्ड, या विफल OTP डिलीवरी — चरण को ऑटो-डिक्लाइन चेतावनी UNDELIVERABLE_EMAIL_DETECTED के साथ Declined के रूप में फ़ाइनलाइज़ करता है। एकमात्र अपवाद: जब उपयोगकर्ता ने स्वयं पता टाइप किया हो (यह सत्र निर्माण के समय प्री-फ़िल नहीं किया गया था), तो डिलीवरी न हो पाने वाला सेंड एक इनलाइन त्रुटि लौटाता है ताकि वे तुरंत अस्वीकृत होने के बजाय किसी भिन्न पते के साथ पुनः प्रयास कर सकें।

स्थिति मान

लाइफ़साइकिल इवेंट प्रकार

lifecycle[] को कालक्रमानुसार क्रमबद्ध किया गया है। प्रत्येक इवेंट में type, timestamp, details और एक बिल योग्य fee (लागू होने पर) शामिल होता है: details payload इवेंट फ़ैमिली पर निर्भर करता है:
  • सेंड इवेंट्स (EMAIL_VERIFICATION_MESSAGE_SENT, EMAIL_VERIFICATION_RETRY_MESSAGE_SENT) — { status, reason }। status Success, Retry या Undeliverable होता है; reason null होता है जब तक कि सेंड विफल न हुआ हो (email_can_not_be_delivered, या अपरिचित लेगसी मानों के लिए unknown)।
  • चेक इवेंट्स (VALID_CODE_ENTERED, INVALID_CODE_ENTERED) — { code_tried, status } जिसमें status Approved, Failed, Expired or Not Found या Declined होता है।
  • अंतिम स्थिति इवेंट्स — null, सिवाय EMAIL_VERIFICATION_DECLINED / EMAIL_VERIFICATION_IN_REVIEW के, जिनमें { "reason": "<risk code>" } (उदाहरण के लिए UNDELIVERABLE_EMAIL_DETECTED) शामिल होता है।
status Success या Undeliverable वाले सेंड में $0.02 ईमेल सत्यापन शुल्क रिकॉर्ड किया जाता है; Retry सेंड, चेक इवेंट्स और स्थिति इवेंट्स में हमेशा fee: 0 होता है।

क्रॉस-सत्र मिलान

matches[] उसी एप्लिकेशन में — KYC, KYB और स्टैंडअलोन API सत्रों में — पहले स्वीकृत ईमेल सत्यापनों में समान पते को रिकॉर्ड करता है, साथ ही प्रबंधन API सूचियाँ में कॉन्फ़िगर किए गए ब्लॉकलिस्ट हिट्स को भी। वर्तमान सत्र के vendor_data को साझा करने वाले सत्यापनों को बाहर रखा जाता है (वही अंतिम उपयोगकर्ता खुद से मेल नहीं खाता है), यह ऐरे अधिकतम 5 प्रविष्टियों तक सीमित है, जो सबसे पुरानी से शुरू होकर क्रमबद्ध होती है। जब पता आपकी ब्लॉकलिस्ट में होता है लेकिन मेल खाने वाले सत्रों में से कोई भी ब्लॉकलिस्टेड नहीं होता है, तो source: "list_entry" (सभी सत्र फ़ील्ड null) के साथ एक सिंथेटिक प्रविष्टि ऐरे के प्रारंभ में जोड़ दी जाती है।

उदाहरण

स्वीकृत — एक सूचनात्मक उल्लंघन के साथ क्लीन OTP

अस्वीकृत — डिलीवरी न होने योग्य पता

एक प्री-फ़िल्ड पता जो सिंटैक्स या DNS (MX) सत्यापन में विफल रहता है — या जिसका OTP ईमेल डिलीवर नहीं किया जा सकता — तुरंत Declined के रूप में फ़ाइनलाइज़ हो जाता है। कोई कोड-चेक इवेंट दिखाई नहीं देते क्योंकि कोई भी कोड कभी उपयोगकर्ता तक नहीं पहुंचा।

अस्वीकृत — ब्लॉकलिस्टेड डिस्पोज़ेबल मेलबॉक्स

उपयोगकर्ता ने OTP पूरा कर लिया, लेकिन पता आपकी ईमेल ब्लॉकलिस्ट से मेल खा गया (ऑटो-डिक्लाइन)। डिस्पोज़ेबल फ़्लैग भी उठाया गया है — यहाँ information स्तर पर क्योंकि disposable_email_action को उसके डिफ़ॉल्ट NO_ACTION पर छोड़ दिया गया है।

संबंधित

अंतिम संशोधन 7 नवंबर 2026