
अवलोकन
हर बार जब कोई वर्कफ़्लो नोड ईमेल सत्यापन सुविधा चलाता है, तो एक ईमेल रिपोर्ट जनरेट होती है। प्रत्येक रिपोर्ट एक पते के विरुद्ध एक OTP चैलेंज का प्रतिनिधित्व करती है और इसमें शामिल हैं:- सत्यापित
emailपता। - बूलियन जोखिम फ़्लैग (
is_breached,is_disposable,is_undeliverable) और ब्रीच-इंटेलिजेंस डेटाबेस से प्राप्त सहायकbreaches[]ऐरे। - OTP भेजने के प्रयासों की संख्या (
verification_attempts) और स्वीकृति टाइमस्टैम्प। - हर बार भेजने, पुनः प्रयास करने और कोड जाँचने का एक कालानुक्रमिक
lifecycle[]लॉग। - अन्य स्वीकृत ईमेल सत्यापनों या आपकी ब्लॉकलिस्ट पर समान पते को सामने लाने वाला एक
matches[]ऐरे। - एक
warnings[]ऐरे — सत्यापन के दौरान उत्पन्न जोखिम इवेंट (देखें ईमेल सत्यापन चेतावनियाँ)। - एक
node_idजो पहचानता है कि किस वर्कफ़्लो ग्राफ़ नोड ने रिपोर्ट जनरेट की (केवल V3 सत्र)।
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] पढ़ने के बजाय)।
स्कीमा
फ़ील्ड-दर-फ़ील्ड कैनोनिकल स्कीमा डेटा मॉडल पेज पर मौजूद है।UNDELIVERABLE_EMAIL_DETECTED के साथ Declined के रूप में फ़ाइनलाइज़ करता है। एकमात्र अपवाद: जब उपयोगकर्ता ने स्वयं पता टाइप किया हो (यह सत्र निर्माण के समय प्री-फ़िल नहीं किया गया था), तो डिलीवरी न हो पाने वाला सेंड एक इनलाइन त्रुटि लौटाता है ताकि वे तुरंत अस्वीकृत होने के बजाय किसी भिन्न पते के साथ पुनः प्रयास कर सकें।
स्थिति मान
लाइफ़साइकिल इवेंट प्रकार
lifecycle[] को कालक्रमानुसार क्रमबद्ध किया गया है। प्रत्येक इवेंट में type, timestamp, details और एक बिल योग्य fee (लागू होने पर) शामिल होता है:
details payload इवेंट फ़ैमिली पर निर्भर करता है:
- सेंड इवेंट्स (
EMAIL_VERIFICATION_MESSAGE_SENT,EMAIL_VERIFICATION_RETRY_MESSAGE_SENT) —{ status, reason }।statusSuccess,RetryयाUndeliverableहोता है;reasonnullहोता है जब तक कि सेंड विफल न हुआ हो (email_can_not_be_delivered, या अपरिचित लेगसी मानों के लिएunknown)। - चेक इवेंट्स (
VALID_CODE_ENTERED,INVALID_CODE_ENTERED) —{ code_tried, status }जिसमेंstatusApproved,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 पर छोड़ दिया गया है।
संबंधित
- ईमेल सत्यापन अवलोकन — सुविधा का व्यवहार और मूल्य निर्धारण।
- ईमेल सत्यापन चेतावनियाँ — प्रत्येक जोखिम कोड, अस्वीकृति ट्रिगर और कॉन्फ़िगर करने योग्य कार्रवाइयाँ।
- डेटा मॉडल — ईमेल सत्यापन — फ़ील्ड-दर-फ़ील्ड कैनोनिकल स्कीमा।
- ईमेल API — OTP भेजना और OTP जाँचना — स्टैंडअलोन सर्वर-टू-सर्वर endpoint।
- प्रबंधन API — सूचियाँ — उस ईमेल ब्लॉकलिस्ट को प्रबंधित करें जो
source: list_entryके साथmatches[]को फ़ीड करती है।