डिस्पोजेबल एड्रेस API: इनबॉक्स ID बनाएं और रोटेट करें

जब आप AI एजेंट, ऑटोमेटेड QA, या हाई-वॉल्यूम साइनअप और वेरिफिकेशन फ़्लो बनाते हैं, तो ईमेल जल्दी ही एक बाधा बन जाता है। पारंपरिक इनबॉक्स को प्रत्येक टास्क के लिए अलग करना कठिन है, रन के बीच रीसेट करना कठिन है, और विश्वसनीय रूप से पार्स करना मुश्किल है। एक डिस्पोजेबल एड्रेस API इसे बदल देता है: प्रत्येक वर्कफ़्लो को अपना इनबॉक्स आइडेंटिफायर (इनबॉक्स ID) मिलता है, आप इसे जब चाहें रोटेट कर सकते हैं, और आपका ऐप HTML स्क्रैप करने के बजाय ईमेल को स्ट्रक्चर्ड डेटा के रूप में प्राप्त करता है।

यह आर्टिकल बताता है कि डिस्पोजेबल एड्रेस API आमतौर पर कैसे काम करता है, इनबॉक्स ID कैसे बनाएं और सुरक्षित रूप से रोटेट करें, और यदि आप इसे LLM एजेंट या ऑटोमेशन में वायर कर रहे हैं तो क्या देखना चाहिए।

“इनबॉक्स ID बनाना और रोटेट करना” का वास्तविक अर्थ

एक डिस्पोजेबल इनबॉक्स सिस्टम में आमतौर पर तीन अवधारणाएं होती हैं:

• इनबॉक्स ID: एक यूनीक आइडेंटिफायर जो आप जेनरेट करते हैं (या प्रोवाइडर जेनरेट करता है) मेलबॉक्स का प्रतिनिधित्व करने के लिए।
• ईमेल एड्रेस: इनबॉक्स ID प्लस एक डोमेन (शेयर्ड डोमेन या आपका कस्टम डोमेन) से व्युत्पन्न। इनकमिंग मेल उस इनबॉक्स पर रूट होता है।
• मैसेज रिट्रीवल: आप मैसेज फेच करते हैं (पोलिंग) या उन्हें प्राप्त करते हैं (webhook) JSON के रूप में।

“रोटेट” का अर्थ है कि आप एक इनबॉक्स ID का उपयोग बंद कर देते हैं और एक नए पर स्विच करते हैं, चाहे प्रति रन, प्रति यूजर, प्रति प्रयास, या एक शेड्यूल पर। रोटेशन आपको आइसोलेशन देता है और क्लीनअप को सरल बनाता है: शेयर्ड मेलबॉक्स से थ्रेड्स को डिलीट करने के बजाय, आप बस ID को छोड़ देते हैं।

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

कब डिस्पोजेबल एड्रेस API सही टूल है (और कब नहीं)

डिस्पोजेबल एड्रेस API आदर्श है जब:

• आपको पैरेलल वर्कफ़्लो के लिए कई इनबॉक्स (सैकड़ों से लाखों) चाहिए।
• आपको ऑटोमेशन चलाने के लिए मशीन-रीडेबल ईमेल (JSON) चाहिए।
• आपको रन के बीच तेज़ रीसेट और आइसोलेशन चाहिए।
• आपको इनबाउंड ईमेल एक इवेंट के रूप में चाहिए (webhooks) ताकि एजेंट नियर रियल टाइम में रिएक्ट कर सकें।

यह कम आदर्श है जब:

• आपको ह्यूमन कोलैबोरेशन फीचर्स के साथ लंबे समय तक चलने वाला मेलबॉक्स चाहिए।
• आपको सेंडिंग, थ्रेडेड कन्वर्सेशन, या पूर्ण “मेल क्लाइंट” कार्यक्षमता चाहिए।

वेरिफिकेशन फ़्लो और QA के लिए, रोटेटिंग डिस्पोजेबल इनबॉक्स ID आमतौर पर सबसे सरल विश्वसनीय पैटर्न है।

डिस्पोजेबल एड्रेस API से अपेक्षित मुख्य क्षमताएं

यदि आप किसी प्रोवाइडर के विरुद्ध डिज़ाइन कर रहे हैं (या चुन रहे हैं), तो ये क्षमताएं निर्धारित करती हैं कि प्रोडक्शन में रोटेशन कितनी अच्छी तरह काम करेगा।

इनबॉक्स लाइफसाइकल कंट्रोल

आप आमतौर पर चाहेंगे:

• इनबॉक्स बनाएं
• इनबॉक्स के लिए मैसेज लिस्ट करें
• ID द्वारा मैसेज प्राप्त करें
• वैकल्पिक इनबॉक्स डिलीट या एक्सपायर करें

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

JSON आउटपुट जो ऑटोमेशन-फ्रेंडली है

ईमेल काफी मुश्किल है। एक प्रोवाइडर जो स्ट्रक्चर्ड JSON में नॉर्मलाइज़ करता है, ब्रिटल पार्सिंग को कम करता है।

कम से कम, उपयोगी फील्ड्स में शामिल हैं:

• From, to, subject, date
• टेक्स्ट बॉडी और HTML बॉडी
• हेडर्स
• अटैचमेंट मेटाडेटा (यदि सपोर्टेड है)

ईमेल हेडर्स और फॉर्मेटिंग पर स्टैंडर्ड्स बैकग्राउंड के लिए, RFC 5322 कैनॉनिकल रेफरेंस है: RFC 5322।

Webhooks या पोलिंग (बेहतर है दोनों)

Webhooks लेटेंसी कम करते हैं और वेस्टेड पोलिंग को रोकते हैं। पोलिंग फ़ायरवॉल्ड एनवायरनमेंट या रिट्राई के लिए फॉलबैक हो सकता है।

उदाहरण के लिए Mailhook, रियल-टाइम webhook नोटिफिकेशन और पोलिंग API दोनों को सपोर्ट करता है, जो एजेंट और टेस्ट रनर्स में मजबूत “ईमेल का इंतज़ार” स्टेप्स बनाना आसान बनाता है।

रेफरेंस आर्किटेक्चर: एजेंट-फ्रेंडली डिस्पोजेबल इनबॉक्स

LLM एजेंट और QA रनर्स के लिए एक सामान्य आर्किटेक्चर इस तरह दिखता है:

1. आपका ऑर्केस्ट्रेटर API के माध्यम से इनबॉक्स ID बनाता है।
2. यह व्युत्पन्न ईमेल एड्रेस को टार्गेट साइट के साइनअप या वेरिफिकेशन फ़्लो में देता है।
3. जब ईमेल आता है, आपका सिस्टम webhook प्राप्त करता है (या पोल करता है)।
4. आपका ऑटोमेशन JSON से वेरिफिकेशन लिंक या कोड निकालता है।
5. रन पूरा होता है और इनबॉक्स ID को रोटेट आउट कर दिया जाता है।

रोटेशन रणनीतियां (फेलियर मोड्स के आधार पर चुनें)

रोटेशन एक साइज़ फिट्स ऑल नहीं है। सही रणनीति इस पर निर्भर करती है कि आप कैसे डिबग करते हैं, रिट्राई को कैसे हैंडल करते हैं, और क्या कई सिस्टम एक ही एड्रेस पर मेल भेज सकते हैं।

रोटेशन रणनीति	बेस्ट फॉर	यह कैसे काम करता है	मुख्य रिस्क	माइटिगेशन
प्रति रन (ephemeral)	QA, CI, लोड टेस्ट्स	हर टेस्ट रन में नई इनबॉक्स ID	यदि इनबॉक्स जल्दी एक्सपायर होता है तो फेलियर के बाद इंस्पेक्ट करना कठिन	अपने लॉग्स या टेस्ट आर्टिफैक्ट्स में मैसेज JSON स्टोर करें
प्रति यूजर सेशन	मल्टी-स्टेप ऑनबोर्डिंग	पूरे सेशन के लिए एक इनबॉक्स	यदि सेशन कॉलाइड होते हैं तो क्रॉस-कंटैमिनेशन	स्ट्रॉन्ग यूनीक ID का उपयोग करें, अपने DB में यूनीकनेस एन्फोर्स करें
प्रति प्रयास (retry-safe)	फ्लैकी ईमेल डिलीवरी	हर रिट्राई प्रयास में नया इनबॉक्स	अधिक इनबॉक्स बनते हैं	TTL और क्लीनअप नीतियां लागू करें
टाइम-बॉक्स्ड (रोटेटिंग विंडो)	लंबे समय तक चलने वाले एजेंट	हर N मिनट/घंटे रोटेट करें	देर से आने वाले ईमेल पुराने इनबॉक्स में आ सकते हैं	ग्रेस विंडो रखें और दोनों इनबॉक्स को मॉनिटर करें

अधिकांश एजेंट वर्कफ़्लो के लिए, प्रति प्रयास सबसे विश्वसनीय है, क्योंकि यह तब अस्पष्टता से बचता है जब एक यूजर या सिस्टम साइनअप को रिट्राई करता है।

एक व्यावहारिक “बनाएं और रोटेट करें” डेटा मॉडल

इनबॉक्स ID को शॉर्ट-लाइव्ड क्रेडेंशियल्स की तरह ट्रीट करें। आपके सिस्टम को उन्हें स्पष्ट रूप से ट्रैक करना चाहिए।

एक साधारण टेबल (या डॉक्यूमेंट) में आमतौर पर जरूरत होती है:

• inbox_id
• email_address
• purpose (उदाहरण के लिए, signup_verification, password_reset, receipt_ingestion)
• run_id या trace_id
• status (active, rotated, expired)
• created_at, rotated_at

यह मॉडल “इस टेस्ट रन के लिए कौन सा इनबॉक्स उपयोग किया गया था?” और “क्या हमें अभी भी इस इनबॉक्स के लिए मैसेज स्वीकार करने चाहिए?” जैसे प्रश्नों का उत्तर देना आसान बनाता है।

इनबॉक्स ID बनाने के लिए उदाहरण फ़्लो (API-अज्ञेयवादी)

प्रोवाइडर सटीक रूट्स और ऑथेंटिकेशन पर अलग होते हैं, लेकिन लॉजिक सुसंगत रहता है।

1) इनबॉक्स बनाएं

अपने प्रोवाइडर के “create inbox” एंडपॉइंट का उपयोग करें और रिटर्न किए गए आइडेंटिफायर को स्टोर करें।

{
  "inbox_id": "inbx_7f3c2a...",
  "address": "[email protected]",
  "created_at": "2026-01-15T15:16:53Z"
}

2) अपने वर्कफ़्लो में एड्रेस का उपयोग करें

address को टार्गेट सिस्टम (साइनअप फॉर्म, OAuth टेस्ट यूजर फ़्लो, B2B इनवाइट, आदि) में पास करें।

3) ईमेल का इंतज़ार करें (webhook-first, polling fallback)

एक मजबूत पैटर्न है:

• नियर रियल-टाइम डिलीवरी के लिए webhooks की सदस्यता लें।
• अस्थायी रूप से webhook डिलीवरी फेल होने के मामले में फॉलबैक के रूप में पोलिंग की अनुमति भी दें।

मेथड	लेटेंसी	ऑपरेशनल कॉम्प्लेक्सिटी	फेलियर मोड्स	बेस्ट प्रैक्टिस
Webhook	कम	मध्यम (एंडपॉइंट, रिट्राई की जरूरत)	एंडपॉइंट डाउनटाइम, सिग्नेचर वेरिफिकेशन फेलियर्स	सिग्नेचर वेरिफाई करें, idempotency implement करें, 2xx फास्ट रिटर्न करें
पोलिंग	मध्यम से उच्च	कम से मध्यम	रेट लिमिट्स, वेस्टेड रिक्वेस्ट्स, धीमे टेस्ट्स	एक्सपोनेंशियल बैकऑफ, टाइमआउट के बाद रुकें

Mailhook सिक्यूरिटी के लिए साइन्ड पेलोड्स को सपोर्ट करता है, जो webhook वेरिफिकेशन के लिए बिल्कुल वही है जो आपको चाहिए।

एजेंट की जरूरत को निकालना (ब्रिटल पार्सिंग के बिना)

अधिकांश वेरिफिकेशन ईमेल इनमें से एक में आ जाते हैं:

• एक लिंक (magic link, confirm email, reset password)
• एक न्यूमेरिक या अल्फान्यूमेरिक कोड (OTP)

यदि आपका प्रोवाइडर text और html दोनों रिटर्न करता है, तो पहले टेक्स्ट को पार्स करना बेहतर है। HTML पार्सिंग अधिक एरर-प्रोन है, खासकर ट्रैकिंग रैपर्स के साथ।

एजेंट के लिए एक व्यावहारिक निकासी दृष्टिकोण:

• यदि प्रोवाइडर लिंक निकासी फील्ड प्रदान करता है तो एक डेडिकेटेड फील्ड को प्राथमिकता दें।
• अन्यथा, URL के लिए टेक्स्ट स्कैन करें और डोमेन allowlist द्वारा चुनें।
• कोड के लिए, अपेक्षित लेंथ और निकटवर्ती कीवर्ड्स (उदाहरण के लिए, “Your code is”) द्वारा बाधित पैटर्न का उपयोग करें।

निकाले गए आर्टिफैक्ट और रॉ मैसेज JSON को अपने रन लॉग्स में एक साथ रखें। यह अमूल्य है जब साइट अपना ईमेल टेम्प्लेट बदल देती है।

इनबॉक्स ID को सुरक्षित रूप से कैसे रोटेट करें

रोटेशन को गलत तरीके से implement करना आसान है। लक्ष्य इनसे बचना है:

• “गलत” रन में देर से आने वाले ईमेल को स्वीकार करना
• रिट्राई के दौरान मैसेज खोना
• रेस कंडीशन बनाना जब कई वर्कर्स स्टेट साझा करते हैं

स्पष्ट स्टेट्स और ग्रेस विंडो का उपयोग करें

एक ठोस दृष्टिकोण है:

• बनाने पर इनबॉक्स को active मार्क करें।
• जब आप रोटेट करते हैं, इसे rotated मार्क करें लेकिन एक छोटी ग्रेस विंडो (उदाहरण के लिए, 10 से 30 मिनट) के लिए इसे readable रखें।
• ग्रेस विंडो के बाद, इसे expired मार्क करें और सुनना बंद करें।

यह देर से डिलीवरी में मदद करता है जबकि आपके सिस्टम को साफ रखता है।

“ईमेल का इंतज़ार” को idempotent बनाएं

यदि आप webhooks का उपयोग करते हैं, तो रिट्राई के कारण एक ही मैसेज एक से अधिक बार डिलीवर हो सकता है। आपका हैंडलर idempotent होना चाहिए।

Typical idempotency key choices:

• प्रोवाइडर मैसेज ID
• हैश ऑफ (inbox_id + subject + date + from)

प्रोसेसेड मैसेज ID स्टोर करें ताकि आपका एजेंट वेरिफिकेशन लिंक्स पर डबल-क्लिक न करे।

समय पर नहीं, फेलियर पर रोटेट करें

साइनअप वेरिफिकेशन में, रोटेट करने का सबसे आम कारण समय बीतना नहीं है, यह अस्पष्टता है:

• यूजर साइनअप रिट्राई करता है।
• टेस्ट रनर फेल्ड टेस्ट को रीरन करता है।
• टार्गेट सिस्टम कई वेरिफिकेशन ईमेल भेजता है।

प्रति प्रयास रोटेट करना प्रत्येक इनबॉक्स को एक “अपेक्षित ईमेल” से जोड़े रखता है, जो एजेंट के रीज़निंग को सरल बनाता है।

डोमेन: शेयर्ड डोमेन बनाम कस्टम डोमेन

कई डिस्पोजेबल इनबॉक्स प्रोवाइडर तत्काल शेयर्ड डोमेन प्रदान करते हैं, और कुछ कस्टम डोमेन को सपोर्ट करते हैं।

शेयर्ड डोमेन टेस्टिंग और internal tooling के लिए सुविधाजनक हैं, लेकिन कस्टम डोमेन मायने रख सकते हैं जब:

• टेस्ट के तहत साइट ज्ञात डिस्पोजेबल डोमेन को ब्लॉक करती है।
• आपको क्लाइंट-फेसिंग ऑपरेशन्स के लिए ब्रांड consistency चाहिए।
• आप डिलीवरेबिलिटी रेप्यूटेशन पर सख्त नियंत्रण चाहते हैं।

यदि आप प्रोडक्शन वेरिफिकेशन फ़्लो (सिर्फ QA नहीं) बना रहे हैं, तो कस्टम डोमेन सपोर्ट अक्सर इसके लायक है।

सिक्यूरिटी और कॉम्प्लायंस बेसिक्स (इसे स्किप न करें)

ईमेल संवेदनशील डेटा (लॉगिन लिंक्स, इनवॉइसेस, PII) ले जा सकता है। यदि आप इसे ऑटोमेशन के माध्यम से रूट कर रहे हैं, तो इनबॉक्स ID को सीक्रेट्स की तरह ट्रीट करें।

मुख्य प्रैक्टिसेज:

• हर इवेंट के लिए webhook signatures को वेरिफाई करें (Mailhook signed payloads को सपोर्ट करता है)।
• least privilege के साथ मैसेज रिट्रीवल एंडपॉइंट्स तक एक्सेस को restrict करें।
• यदि आप ईमेल JSON को persist करते हैं तो stored message data को encrypt करें।
• लॉग्स में secrets को redact करें (वेरिफिकेशन लिंक्स अक्सर टोकन include करते हैं)।
• retention policies सेट करें (डिबगिंग और कॉम्प्लायंस के लिए जो जरूरी है वही रखें)।

Webhook signature verification patterns के लिए, Stripe के webhook docs best practices का व्यापक रूप से संदर्भित उदाहरण हैं: Stripe: verifying webhooks।

QA ऑटोमेशन: टेस्ट सूट्स के लिए एक साफ पैटर्न

यदि आपका लक्ष्य CI स्थिरता है, तो डिस्पोजेबल इनबॉक्स पैटर्न को flakiness को कम करना चाहिए:

• प्रति टेस्ट केस इनबॉक्स जेनरेट करें (या प्रति टेस्ट क्लास यदि सूट बहुत बड़ा है)।
• bounded timeout के साथ ईमेल का इंतज़ार करें।
• यदि timeout होता है, रोटेट करें और एक बार रिट्राई करें (और फेलियर में raw message logs attach करें)।

कई टेस्ट्स को एक ही इनबॉक्स के विरुद्ध चलाने से बचें। शेयर्ड इनबॉक्स nondeterminism बनाते हैं, जो विश्वसनीय CI का दुश्मन है।

LLM एजेंट: ईमेल को टूल बनाना, न कि distraction

एजेंट तब सबसे अच्छा प्रदर्शन करते हैं जब टूल्स निर्धारित होते हैं। एक इनबॉक्स जो structured JSON रिटर्न करता है एक अच्छा टूल इंटरफेस है, क्योंकि यह “interpretation” काम को कम करता है।

यदि आप एजेंट टूल स्पेक बना रहे हैं, तो define करें:

• create_inbox(purpose, run_id) -> {inbox_id, address}
• wait_for_message(inbox_id, timeout_s) -> {message_json}
• rotate_inbox(inbox_id) -> {new_inbox_id, new_address}

एजेंट को इन्फ्रास्ट्रक्चर डिटेल्स (जैसे backoff logic, webhook retries, signature verification) से बाहर रखें। अपने orchestrator को इसे handle करने दें, और clean primitives expose करें।

Mailhook कहां फिट करता है

Mailhook विशेष रूप से प्रोग्रामेबल डिस्पोजेबल इनबॉक्स के लिए बनाया गया है: आप API के माध्यम से इनबॉक्स बना सकते हैं, ईमेल को structured JSON के रूप में प्राप्त कर सकते हैं, और webhooks या polling के माध्यम से integrate कर सकते हैं। यदि आपको डिस्पोजेबल एड्रेस API चाहिए जो AI एजेंट और ऑटोमेटेड वर्कफ़्लो के साथ अच्छी तरह से काम करे, तो यह इस “इनबॉक्स ID बनाएं और रोटेट करें” पैटर्न के लिए एक प्रत्यक्ष मैच है।

आप Mailhook पर प्रोडक्ट एक्सप्लोर कर सकते हैं।