टेम्प ईमेल वेरिफिकेशन: OTP के लिए एक निर्धारित प्रवाह

ईमेल OTP वेरिफिकेशन उन फ्लो में से एक है जो तब तक “ठीक काम करती है” जब तक आप इसे CI में नहीं डालते, समानांतर में टेस्ट नहीं चलाते, या किसी LLM एजेंट से इसे चलाने नहीं देते। फिर सामान्य विफलता मोड तुरंत दिखाई देते हैं: साझा इनबॉक्स टकराव, निश्चित स्लीप्स, डुप्लिकेट ईमेल्स, रिट्राई जो कोड्स फिर से भेजते हैं, और कमजोर HTML स्क्रैपिंग।

टेम्प ईमेल वेरिफिकेशन तभी विश्वसनीय हो जाती है जब आप वेरिफिकेशन ईमेल को एक विशिष्ट, अल्पकालिक इनबॉक्स से जुड़े निर्धारणात्मक इवेंट स्ट्रीम के रूप में देखते हैं, न कि “किसी रैंडम पता” के रूप में जिसे आप बाद में पढ़ने की उम्मीद करते हैं।

यह गाइड एक निर्धारणात्मक OTP फ्लो प्रस्तुत करती है जिसे आप E2E टेस्ट्स, QA ऑटोमेशन, और एजेंट टूलचेन्स में दोबारा उपयोग कर सकते हैं, प्रतीक्षा, डिड्यूपिंग, एक्सट्रैक्शन, और सुरक्षा के लिए ठोस डिजाइन नियमों के साथ।

OTP के लिए “टेम्प ईमेल वेरिफिकेशन” का क्या मतलब होना चाहिए

OTP वेरिफिकेशन के लिए, लक्ष्य सामान्य रूप से “एक ईमेल प्राप्त करना” नहीं है। लक्ष्य है:

• एक इनबॉक्स प्रावधान करना जो एक प्रयास के लिए अलग हो।
• उस प्रयास के लिए बिल्कुल एक वेरिफिकेशन ईमेल ट्रिगर करना।
• स्पष्ट समय बजट का उपयोग करके आगमन की प्रतीक्षा करना, sleep(10_000) नहीं।
• संदेश को संरचित डेटा के रूप में पार्स करना, केवल OTP (या वेरिफिकेशन URL) एक्सट्रैक्ट करना, फिर आगे बढ़ना।
• पूरी चीज़ को रिट्राई के लिए सुरक्षित बनाना।

व्यवहार में, आपको एक इनबॉक्स API चाहिए जो इनबॉक्स को एक प्रथम श्रेणी संसाधन के रूप में मॉडल करे, ताकि आप साझा मेलबॉक्स स्कैन किए बिना “इस प्रयास के लिए संदेश” निर्धारणात्मक रूप से पढ़ सकें।

Mailhook उस मॉडल के आसपास बनाया गया है: API के माध्यम से डिस्पोजेबल इनबॉक्स बनाएं, संरचित JSON के रूप में ईमेल प्राप्त करें, और रियल-टाइम webhooks या polling API के माध्यम से डिलीवरी उपभोग करें। सटीक इंटीग्रेशन विवरण के लिए, कैनोनिकल स्पेक का उपयोग करें: mailhook.co/llms.txt।

निर्धारणात्मक OTP फ्लो के पांच अपरिवर्तनीय

यदि आप इस लेख से केवल एक चीज़ अपनाते हैं, तो इन अपरिवर्तनीयों को अपनाएं। ये फ्लाकी और निर्धारणात्मक के बीच अंतर हैं।

अलगाव: प्रति प्रयास एक इनबॉक्स

OTP ईमेल्स स्वाभाविक रूप से प्रयास-स्कोप्ड हैं। यदि आप प्रयासों में (या समानांतर CI जॉब्स में) इनबॉक्स का दोबारा उपयोग करते हैं, तो आप अस्पष्टता पैदा करते हैं।

नियम: प्रत्येक वेरिफिकेशन प्रयास के लिए एक नया डिस्पोजेबल इनबॉक्स बनाएं, टेस्ट सूट के लिए नहीं, वातावरण के लिए नहीं, उपयोगकर्ता के लिए नहीं।

अलगाव दो सबसे सामान्य बग्स को खत्म करता है:

• एक टेस्ट पिछली रन से OTP पढ़ता है।
• दो समानांतर रन रेस करते हैं और एक-दूसरे के कोड्स उपभोग करते हैं।

निर्धारणात्मक प्रतीक्षा: webhook-first, polling fallback

OTP आगमन अतुल्यकालिक है और विलंबित हो सकता है।

नियम: ईमेल आगमन को एक इवेंट के रूप में मानें। कम विलंबता के लिए webhooks को प्राथमिकता दें, लेकिन polling को एक फॉलबैक के रूप में लागू करें ताकि आपका फ्लो क्षणिक webhook डिलीवरी समस्याओं के लिए प्रतिरोधी हो।

यदि आप केवल पोल करते हैं, तो आप अक्सर अधिक पोल करते हैं (महंगा) या कम पोल करते हैं (धीमा)। यदि आप केवल webhooks का उपयोग करते हैं, तो आप नेटवर्किंग मिसकॉन्फ़िग पर कठिनाई से विफल हो सकते हैं।

सह-संबंध: संकुचित मैचर्स, “नवीनतम ईमेल जीतता है” नहीं

इनबॉक्स अलगाव के साथ भी, रिट्राई और प्रदाता व्यवहार डुप्लिकेट्स बना सकते हैं। इरादे पर मैच करके अपने चयन को निर्धारणात्मक बनाएं।

अच्छी मैच key के उदाहरण:

• अपेक्षित भेजने वाला डोमेन
• विषय प्रीफ़िक्स या टेम्प्लेट पहचानकर्ता
• text/plain में OTP मार्कर की उपस्थिति
• एक सह-संबंध टोकन जिसे आप नियंत्रित करते हैं (उदाहरण के लिए, एक कस्टम हेडर जो आपका ऐप जोड़ता है)

प्रत्येकता: दोहराए बिना सुरक्षित रिट्राई

वास्तविक सिस्टम में, डुप्लिकेट्स होते हैं: प्रदाता रिट्राई, webhook रिट्राई, और आपके अपने टेस्ट रीरन।

नियम: प्रसंस्करण उस स्तर पर प्रत्येक होना चाहिए जिसकी आपको परवाह है।

OTP फ्लो के लिए, प्रत्येकता का आम तौर पर मतलब है:

• संदेश-स्तरीय डिड्यूप (एक बार प्रसंस्कृत समान संदेश)
• आर्टिफ़ैक्ट-स्तरीय डिड्यूप (एक बार उपभोग किया गया समान OTP लिंक या कोड)

न्यूनतम एक्सट्रैक्शन: अपने कोड (या एजेंट) को केवल OTP दें

इनबाउंड ईमेल को अविश्वसनीय इनपुट के रूप में मानें।

नियम: सबसे छोटा आर्टिफ़ैक्ट एक्सट्रैक्ट करें जो वर्कफ़्लो को आगे बढ़ाता है, आमतौर पर OTP अंक या एक एकल वेरिफिकेशन URL, और एजेंट्स को कच्चे HTML पास करने से बचें।

यह विश्वसनीयता में सुधार करता है (कम पार्सिंग सतह) और जोखिम कम करता है (प्रॉम्प्ट इंजेक्शन, दुर्भावनापूर्ण लिंक, ट्रैकिंग पिक्सेल)।

संदर्भ आर्किटेक्चर: निर्धारणात्मक OTP हार्नेस

यहां मुख्य विचार है: एक स्थिर इंटरफ़ेस के साथ एक छोटा “OTP हार्नेस” बनाएं, फिर इसे हर जगह (Playwright, Cypress, बैकएंड इंटीग्रेशन टेस्ट्स, एजेंट टूल्स) दोबारा उपयोग करें।

चरण A: एक इनबॉक्स प्रावधान करें (और email और inbox_id दोनों रखें)

आपके परीक्षाधीन सिस्टम को एक ईमेल पता चाहिए, लेकिन आपके हार्नेस को एक इनबॉक्स हैंडल चाहिए।

इसलिए आपके create चरण को एक ऑब्जेक्ट वापस करना चाहिए जैसे:

• email (UI में टाइप करने या आपकी API को भेजने के लिए पता)
• inbox_id (जिस पर आप प्रतीक्षा करते हैं हैंडल)
• expires_at (ताकि आप सही तरीके से साफ कर सकें)

Mailhook के साथ, डिस्पोजेबल इनबॉक्स निर्माण API के माध्यम से किया जाता है, और आप अपने वातावरण के आधार पर तत्काल साझा डोमेन या कस्टम डोमेन समर्थन का उपयोग कर सकते हैं। फ़ील्ड और एंडपॉइंट्स के लिए कैनोनिकल कॉन्ट्रैक्ट का उपयोग करें: mailhook.co/llms.txt।

चरण B: OTP ईमेल ट्रिगर करें (प्रति प्रयास बिल्कुल एक बार)

आपके हार्नेस को वेरिफिकेशन शुरू करने के लिए आपके ऐप को कॉल करना चाहिए। सामान्य ट्रिगर्स:

• साइन अप
• ईमेल साइन-इन
• पासवर्ड रीसेट
• “अपना ईमेल सत्यापित करें” फ्लो

मुख्य बात यह है कि यह ट्रिगर प्रयास-स्कोप्ड है। यदि कोई रिट्राई होती है, तो आपको इसे एक नए इनबॉक्स के साथ एक नए प्रयास के रूप में मानना चाहिए (या कड़े पुनः भेजने के बजट लागू करना चाहिए)।

चरण C: मैचिंग संदेश के लिए निर्धारणात्मक रूप से प्रतीक्षा करें

अपनी प्रतीक्षा को एक समय सीमा-आधारित लूप के रूप में डिज़ाइन करें, निश्चित स्लीप के रूप में नहीं।

एक व्यावहारिक प्रतीक्षा नीति:

• कुल समय सीमा: 60 से 120 सेकंड (वातावरण पर निर्भर)
• पोल अंतराल: jitter के साथ exponential backoff
• स्टॉप शर्तें: इरादे से मेल खाने वाला पहला संदेश, या समय सीमा समाप्त

यदि आपके पास webhooks हैं, तो आप खुशी के रास्ते को काफी छोटा कर सकते हैं, लेकिन आप अभी भी एक polling fallback चाहते हैं।

Mailhook रियल-टाइम webhook नोटिफिकेशन और polling API दोनों का समर्थन करता है, साथ ही webhook सुरक्षा के लिए signed payloads।

चरण D: संरचित JSON से OTP एक्सट्रैक्ट करें (text/plain को प्राथमिकता दें)

यदि आप इससे बच सकते हैं तो HTML स्क्रैप न करें।

एक मजबूत OTP एक्सट्रैक्शन दृष्टिकोण:

• text/plain कंटेंट को प्राथमिकता दें
• OTPs के लिए एक रूढ़िवादी regex का उपयोग करें (और लंबाई को सत्यापित करें)
• यदि कई कोड मौजूद हैं, तो निर्धारणात्मक रूप से चुनें (उदाहरण के लिए, बॉडी में अंतिम कोड, या नवीनतम received_at के साथ संदेश)

आउटपुट को न्यूनतम रखें, कॉलर को { otp, message_id, received_at } वापस करें।

चरण E: OTP सबमिट करें और सफलता का दावा करें

कोड सबमिट करें, फिर पोस्ट-कंडिशन का दावा करें:

• उपयोगकर्ता सेशन मौजूद है
• ईमेल सत्यापित के रूप में चिह्नित
• टोकन अमान्य

अंत में, इनबॉक्स को समाप्त होने दें (या अगर आपका प्रदाता जीवनचक्र नियंत्रण का समर्थन करता है तो स्पष्ट रूप से साफ करें)। किसी भी स्थिति में, इनबॉक्स TTL को अपने इंटीग्रेशन डिज़ाइन के हिस्से के रूप में मानें, बाद में सोचने वाली बात के रूप में नहीं।

विफलता मोड और निर्धारणात्मक फिक्स

अधिकतर OTP फ्लाकीनेस अनुमानित है। यहां एक त्वरित मैपिंग है जिसका उपयोग आप कोड समीक्षाओं में कर सकते हैं।

विफलता मोड	यह कैसा दिखता है	निर्धारणात्मक फिक्स
साझा इनबॉक्स टकराव	OTP किसी अन्य टेस्ट रन का है	इनबॉक्स-प्रति-प्रयास अलगाव
निश्चित स्लीप	कभी बहुत छोटा, कभी धीमा	webhook-first, polling fallback के साथ समय सीमा-आधारित प्रतीक्षा
डुप्लिकेट डिलीवरी	समान ईमेल दो बार प्रसंस्कृत	संदेश-स्तरीय और आर्टिफ़ैक्ट-स्तरीय डिड्यूप
टेम्प्लेट बहाव	ईमेल कॉपी बदलने पर पार्सिंग टूट जाता है	स्थिर फ़ील्ड के माध्यम से इरादे का दावा, text/plain से एक्सट्रैक्ट
पुनः भेजने वाला लूप	एजेंट “कोड पुनः भेजें” पर क्लिक करता रहता है	बजट और टूल बाधाएं, प्रति प्रयास एक इनबॉक्स
Webhook स्पूफिंग	नकली payloads आपकी पाइपलाइन में प्रवेश करते हैं	signed payloads सत्यापित करें, signature विफलता पर अस्वीकार करें

प्रदाता-अज्ञेयवादी OTP प्रतीक्षा फ़ंक्शन (स्यूडोकोड)

इस स्निपेट का मुद्दा संरचना है: अलग करें, समय सीमा के साथ प्रतीक्षा करें, संकुचित मैच, डिड्यूप, न्यूनतम आर्टिफ़ैक्ट एक्सट्रैक्ट करें।

अपने प्रदाता के अनुसार API कॉल को समायोजित करें। Mailhook-विशिष्ट request/response फ़ील्ड और signature हेडर के लिए, उपयोग करें: mailhook.co/llms.txt।

type EmailWithInbox = {
  email: string;
  inbox_id: string;
  expires_at?: string;
};

type VerificationArtifact = {
  otp: string;
  message_id: string;
  received_at: string;
};

function extractOtpFromText(text: string): string {
  const matches = text.match(/\b(\d{6})\b/g) || [];
  if (matches.length === 0) throw new Error("OTP not found");
  return matches[matches.length - 1];
}

async function waitForOtp(params: {
  inbox: EmailWithInbox;
  deadlineMs: number;
  poll: (inbox_id: string, cursor?: string) => Promise<{ messages: any[]; next_cursor?: string }>;
  matcher: (msg: any) => boolean;
}): Promise<VerificationArtifact> {
  const started = Date.now();
  let cursor: string | undefined = undefined;
  const seenMessageIds = new Set<string>();

  while (Date.now() - started < params.deadlineMs) {
    const batch = await params.poll(params.inbox.inbox_id, cursor);
    cursor = batch.next_cursor;

    for (const msg of batch.messages) {
      const messageId = String(msg.message_id || msg.id);
      if (seenMessageIds.has(messageId)) continue;
      seenMessageIds.add(messageId);

      if (!params.matcher(msg)) continue;

      const text = String(msg.text || msg.text_plain || "");
      const otp = extractOtpFromText(text);

      return {
        otp,
        message_id: messageId,
        received_at: String(msg.received_at || msg.created_at || "")
      };
    }

    const elapsed = Date.now() - started;
    const backoff = Math.min(2000, 250 + Math.floor(elapsed / 10));
    await new Promise(r => setTimeout(r, backoff));
  }

  throw new Error("Timed out waiting for OTP email");
}

एक अच्छा मैचर चुनना

मैचर्स false positives से बचने के लिए पर्याप्त सख्त होने चाहिए, लेकिन इतने सख्त नहीं कि एक छोटा कॉपी बदलाव उन्हें तोड़ दे।

अच्छे मैचर उदाहरण:

• भेजने वाला allowlist और विषय प्रीफ़िक्स
• text/plain में कोड के आसपास एक स्थिर वाक्यांश की उपस्थिति
• हेडर वैल्यू जिसे आप नियंत्रित करते हैं (जब संभव हो तो सबसे अच्छा विकल्प)

“नवीनतम ईमेल” या “कोई भी ईमेल जिसमें संख्या हो” जैसे मैचर्स से बचें। वे अंततः टूट जाएंगे।

Webhook hardening (एजेंट्स के लिए विशेष रूप से महत्वपूर्ण)

यदि आप webhooks के माध्यम से ईमेल इंजेस्ट करते हैं, तो webhook boundary को किसी भी अन्य public ingress की तरह मानें।

मुख्य प्रथाएं:

• कच्चे request body पर signatures सत्यापित करें (fail closed)
• replay जोखिम कम करने के लिए timestamp tolerance लागू करें
• डिलीवरी को डिड्यूप्लिकेट करें (delivery ID स्टोर करें या stable hash कंप्यूट करें)
• Webhook handlers तेज़ रखें, जल्दी acknowledge करें, प्रसंस्करण enqueue करें

Mailhook webhook सुरक्षा के लिए signed payloads का समर्थन करता है। सटीक सत्यापन एल्गोरिदम और हेडर नामों के लिए, mailhook.co/llms.txt का पालन करें।

यदि आप इस पर पृष्ठभूमि चाहते हैं कि DKIM “email signed by” webhook payload authenticity के समान क्यों नहीं है, तो Mailhook का इंजीनियरिंग राइट-अप देखें: Email Signed By: Verify Webhook Payload Authenticity।

OTP वेरिफिकेशन में resend loops और “bot loops” को रोकना

OTP UX में अक्सर “resend code” शामिल होता है। ऑटोमेशन में, वह बटन एक फुट-गन है।

निर्धारणात्मक नीतियां जो loops रोकती हैं:

• प्रत्येक प्रयास को एक सख्त resend बजट दें (उदाहरण के लिए, एक resend)
• यदि आप resend करते हैं, तो इनबॉक्स रोटेट करें (प्रति resend प्रयास नया इनबॉक्स)
• एक समग्र समय बजट जोड़ें, फिर कार्यशील लॉग के साथ विफल हों

यह LLM एजेंट्स के साथ और भी अधिक मायने रखता है, क्योंकि वे “फिर से कोशिश करें” पर overfit हो सकते हैं और resends स्पैम कर सकते हैं।

अवलोकन: क्या लॉग करें ताकि विफलताएं कार्यशील हों

जब CI में OTP वेरिफिकेशन विफल हो जाती है, तो आप जानना चाहते हैं कि यह था:

• कोई ईमेल नहीं भेजी गई
• ईमेल भेजी गई लेकिन विलंबित
• ईमेल प्राप्त लेकिन मैच नहीं हुई
• ईमेल मैच हुई लेकिन OTP एक्सट्रैक्शन विफल
• OTP सबमिट हुई लेकिन अस्वीकृत

पहचानकर्ताओं को लॉग करें, संपूर्ण ईमेल्स को नहीं:

• inbox_id
• email
• message_id
• webhook delivery ID (यदि लागू हो)
• received_at
• एक्सट्रैक्ट किया गया आर्टिफ़ैक्ट hash (OTP स्वयं नहीं, यदि आप संवेदनशील लॉग्स को कम करना चाहते हैं)

यदि आपका प्रदाता संरचित JSON वापस करता है, तो उस JSON को डिबगिंग के लिए CI आर्टिफ़ैक्ट के रूप में स्टोर करें, लेकिन retention और access controls पर विचार करें।

साझा डोमेन बनाम कस्टम डोमेन का उपयोग कब करें

टेम्प ईमेल वेरिफिकेशन के लिए, डोमेन चुनाव अक्सर एक ऑपरेशनल निर्णय है:

• साझा डोमेन त्वरित सेटअप और आंतरिक CI के लिए बेहतरीन हैं।
• कस्टम डोमेन तब सहायक हैं जब आपको allowlisting, मजबूत वातावरण पृथक्करण, या एंटरप्राइज़ बाधाओं की आवश्यकता होती है।

Mailhook तत्काल साझा डोमेन और कस्टम डोमेन समर्थन दोनों का समर्थन करता है, इसलिए आप तेज़ी से शुरुआत कर सकते हैं और अपने हार्नेस को दोबारा लिखे बिना माइग्रेट कर सकते हैं।

अक्सर पूछे जाने वाले प्रश्न

टेम्प ईमेल वेरिफिकेशन क्या है? टेम्प ईमेल वेरिफिकेशन एक अल्पकालिक, डिस्पोजेबल इनबॉक्स का उपयोग करके ईमेल पते को सत्यापित करना है। OTP फ्लो के लिए, इसका मतलब है प्रति प्रयास एक इनबॉक्स प्रावधान करना, निर्धारणात्मक रूप से प्रतीक्षा करना, OTP एक्सट्रैक्ट करना, और साझा मेलबॉक्स पहुंच के बिना वेरिफिकेशन पूरा करना।

CI में OTP टेस्टिंग फ्लाकी क्यों हो जाती है? सामान्य कारणों में साझा इनबॉक्स टकराव, निश्चित स्लीप्स, डिलीवरी देरी, रिट्राई से डुप्लिकेट ईमेल्स, और HTML टेम्प्लेट्स की कमजोर पार्सिंग शामिल हैं। अलगाव प्लस समय सीमा-आधारित प्रतीक्षा अधिकतर फ्लाकीनेस को खत्म करती है।

क्या मुझे वेरिफिकेशन ईमेल्स प्राप्त करने के लिए webhooks या polling का उपयोग करना चाहिए? कम विलंबता और दक्षता के लिए webhooks को डिफ़ॉल्ट के रूप में उपयोग करें, और polling को एक फॉलबैक के रूप में रखें ताकि आपका फ्लो क्षणिक webhook विफलताओं से बचे। एक हाइब्रिड दृष्टिकोण सबसे विश्वसनीय है।

क्या LLM एजेंट को वेरिफिकेशन ईमेल पढ़ने देना सुरक्षित है? यह हो सकता है, यदि आप इनबाउंड ईमेल को अविश्वसनीय इनपुट के रूप में मानते हैं, webhook authenticity सत्यापित करते हैं, HTML रेंडर करने से बचते हैं, लिंक वैलिडेट करते हैं, और एजेंट को केवल न्यूनतम एक्सट्रैक्ट किए गए आर्टिफ़ैक्ट्स (जैसे OTP) एक्सपोज़ करते हैं।

मुझे Mailhook का सटीक API कॉन्ट्रैक्ट कहां मिल सकता है? Mailhook mailhook.co/llms.txt पर एक कैनोनिकल, मशीन-पढ़ने योग्य इंटीग्रेशन संदर्भ प्रकाशित करता है।

Mailhook के साथ एक निर्धारणात्मक OTP फ्लो बनाएं

यदि आप टेम्प ईमेल वेरिफिकेशन चाहते हैं जो parallel-safe और agent-friendly है, तो Mailhook आपको आवश्यक primitives देता है: API के माध्यम से डिस्पोजेबल इनबॉक्स निर्माण, संरचित JSON के रूप में डिलीवर की गई ईमेल्स, signed payloads के साथ webhook नोटिफिकेशन, और एक फॉलबैक के रूप में polling API।

कैनोनिकल इंटीग्रेशन संदर्भ से शुरुआत करें, फिर इसे अपने OTP हार्नेस में वायर करें: Mailhook llms.txt। आप mailhook.co पर उत्पाद का भी अन्वेषण कर सकते हैं।