एजेंट मेलबॉक्स

एजेंट मेलबॉक्स एक पता-योग्य इनबॉक्स है जिसे आपका कोड API के ज़रिए मैनेज करता है। इसके थ्रेड्स पढ़ें और फ़िल्टर करें, मैसेज का जवाब दें, या नया मेल कंपोज़ करें, बिना IMAP सर्वर चलाए या रॉ MIME पार्स किए।

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

पते

हर मेलबॉक्स का एक पता होता है, {local_part}@inbox.ai। आप दो तरीकों से पता पा सकते हैं:

जेनरेटेड: लोकल पार्ट छोड़ दें और हम आपके लिए एक कॉलिज़न-फ़्री पार्ट जेनरेट कर देंगे (a7f3k2@inbox.ai)। हमेशा उपलब्ध।
कस्टम: कोई विशेष लोकल पार्ट माँगें (support@inbox.ai)। कस्टम हैंडल वैश्विक रूप से अद्वितीय हैं, पहले आओ पहले पाओ के आधार पर, और पेड-प्लान अलाउंस का हिस्सा हैं; फ़्री वर्कस्पेस जेनरेटेड पते इस्तेमाल करता है।

पता बनने के बाद अपरिवर्तनीय होता है। बदलने के लिए नया मेलबॉक्स बनाएँ और पुराना हटा दें। पुराना लोकल पार्ट 30 दिन (उसकी रिस्टोर विंडो) तक होल्ड रहता है, उसके बाद ही फिर से क्लेम किया जा सकता है, और आपके वर्कस्पेस के लिए आरक्षित बना रहता है।

थ्रेड्स और मैसेज

प्राप्त और भेजे गए मेल को थ्रेड्स में समूहित किया जाता है, हर बातचीत के लिए एक। थ्रेड में भाग लेने वाले पते, अपठित संख्या, उसके नवीनतम मैसेज की दिशा (inbound या outbound), और सबसे हालिया गतिविधि का टाइमस्टैम्प होता है। जवाब उसी थ्रेड में जुड़ जाते हैं; नया कंपोज़ एक नया थ्रेड शुरू करता है।

हर मैसेज हेडर, उद्धृत इतिहास हटाकर निकाला गया प्लेन टेक्स्ट, और अटैचमेंट दिखाता है। मूल बॉडी 30 दिन तक उपलब्ध रहती है; रॉ MIME केवल प्राप्त मैसेज के लिए उपलब्ध है। मैसेज ID दिशा के अनुसार प्रीफ़िक्स्ड होते हैं: प्राप्त मैसेज के लिए rem_, आपके भेजे हुए के लिए em_।

क्या अंदर आएगा, यह तय करना

इनबॉक्स के सामने दो नियंत्रण हैं, दोनों जालसाज़ी-योग्य From: हेडर की बजाय एनवेलप सेंडर के विरुद्ध जाँचे जाते हैं:

रिसीव पॉलिसी: मेलबॉक्स-व्यापी डिफ़ॉल्ट।
- open प्रमाणीकरण पास करने वाली हर चीज़ स्वीकार करता है।
- replies_only केवल वह मेल स्वीकार करता है जो मेलबॉक्स में पहले से मौजूद किसी थ्रेड को जारी रखता है।
- allowlist केवल उन्हीं सेंडर्स को स्वीकार करता है जिन्हें आपके नियम अनुमति देते हैं, साथ ही मौजूदा थ्रेड के जवाब भी।
- drop सब कुछ रद्द करता है, कोई अपवाद नहीं।
रिसीव रूल्स: प्रति-सेंडर अनुमति या ब्लॉक एंट्रीज़, जो पूरे पते या डोमेन पर मैच होती हैं (डोमेन रूल उसके सबडोमेन से भी मैच करता है)। ब्लॉक हमेशा अनुमति पर भारी पड़ता है।

जो मेल किसी रूल से ब्लॉक होता है, या DMARC में फ़ेल होता है, वह फिर भी मेलबॉक्स में स्टोर रहता है और पढ़ने योग्य बना रहता है: उसे इनबॉक्स से बाहर फ़ाइल किया जाता है, हटाया नहीं जाता, और कोई webhook ट्रिगर नहीं होता। एकमात्र अपवाद drop पर सेट मेलबॉक्स है, जो फ़ाइल करने की बजाय सब कुछ दरवाज़े पर ही रद्द कर देता है।

भेजना

मेलबॉक्स API के ज़रिए दो तरीकों से भेजता है: किसी मैसेज का जवाब दें (आउटबाउंड मैसेज उसी थ्रेड में जुड़ जाता है) या नया मैसेज कंपोज़ करें (जो एक नया थ्रेड शुरू करता है)। डैशबोर्ड में कोई मैसेज खोलें और Forward चुनें ताकि उसकी मूल बॉडी और अटैचमेंट नए प्राप्तकर्ताओं को भेजे जा सकें, मूल कंटेंट की 30-दिन की विंडो के भीतर। मेल मेलबॉक्स के अपने पते से भेजा जाता है, उस पर कॉन्फ़िगर किए गए डिस्प्ले नेम और डिफ़ॉल्ट Reply-To के साथ। डिलीवरी स्टेटस भेजे गए मैसेज पर वापस दिखता है, ताकि आप देख सकें कि जवाब डिलीवर हुआ या बाउंस।

इवेंट्स

बिना पोलिंग के एजेंट चलाने के लिए email_mailbox.* webhook फ़ैमिली को सब्सक्राइब करें: email_mailbox.message_received (इनबाउंड मेल इनबॉक्स में पहुँचा), email_mailbox.thread_created, और आपके भेजे गए मैसेज के डिलीवरी-स्टेटस इवेंट्स। केवल इनबॉक्स मेल फ़ैन आउट होता है; स्पैम और रूल-ब्लॉक्ड मेल चुपचाप स्टोर होता है, ताकि भरा हुआ मेलबॉक्स webhook की बाढ़ में न बदले। इनबॉक्स मेल स्टैंडर्ड email.received इवेंट भी फ़ायर करता है, ताकि मौजूदा इनबाउंड इंटीग्रेशन काम करता रहे।

webhook इन्फ़्रास्ट्रक्चर के बिना लाइव व्यू के लिए GET /v1/email/mailboxes/{mailbox_id}/events से कनेक्ट करें। SSE स्ट्रीम मेलबॉक्स गतिविधि के लिए इवेंट टाइप, थ्रेड ID और मैसेज ID भेजती है, जिसमें स्पैम और ब्लॉक्ड मेल भी शामिल है। उन ID से पूरे मैसेज फ़ेच करें। स्ट्रीम डिस्कनेक्ट के बाद इवेंट्स रीप्ले नहीं करती। टिकाऊ डिलीवरी के लिए webhook इस्तेमाल करें, और गैप के बाद अपडेट पाने के लिए लिस्ट एंडपॉइंट्स इस्तेमाल करें।

रिटेंशन और मिटाना

मेलबॉक्स का रिटेंशन टियर यह नियंत्रित करता है कि आप मैसेज हेडर, निकाला गया टेक्स्ट और मेलबॉक्स अटैचमेंट कितने समय तक पढ़ सकते हैं, भेजने या प्राप्त होने से मापा जाता है। डिफ़ॉल्ट 30 दिन है। अगर आपके प्लान में 90-दिन या 365-दिन का रिटेंशन शामिल है, तो बनाते या अपडेट करते समय retention_tier सेट करें। आपके प्लान में शामिल न होने वाला टियर E17048 के साथ अस्वीकार कर दिया जाता है।

कंटेंट या कार्रवाई	रिटेंशन विंडो
मैसेज हेडर, निकाला गया टेक्स्ट, और मेलबॉक्स अटैचमेंट	चुना गया टियर: 30, 90, या 365 दिन
मूल HTML और प्लेन-टेक्स्ट बॉडी	हर टियर पर 30 दिन
प्राप्त मैसेज का रॉ MIME	हर टियर पर 30 दिन; भेजे गए मैसेज का कोई स्टोर्ड रॉ MIME नहीं
डैशबोर्ड में मैसेज फ़ॉरवर्ड करना	मूल कंटेंट उसकी 30-दिन की विंडो के भीतर ज़रूरी
निकाला गया टेक्स्ट पढ़ना या नए कंटेंट के साथ जवाब देना	मैसेज रिटेन रहने तक उपलब्ध

उदाहरण के लिए, दिन 40 पर 90-दिन वाले मेलबॉक्स में मैसेज का निकाला गया टेक्स्ट अभी भी पढ़ने योग्य, खोजने योग्य होता है और अटैचमेंट रिटेन रहते हैं। आप नए कंटेंट के साथ जवाब दे सकते हैं, लेकिन मूल बॉडी नहीं खोल सकते, उसका रॉ MIME डाउनलोड नहीं कर सकते, या उसे फ़ॉरवर्ड नहीं कर सकते। निकाला गया टेक्स्ट प्रति मैसेज 64 KiB तक सीमित है और मूल के कुछ हिस्से छूट सकते हैं। एक्सटेंडेड अटैचमेंट रिटेंशन सक्षम होने से पहले स्टोर किए गए अटैचमेंट अपनी मूल एक्सपायरी लगभग 31 दिन रखते हैं; टियर बदलने से वे माइग्रेट नहीं होते। टियर बढ़ाने से पहले ही हट चुका कंटेंट वापस नहीं आ सकता।

रिटेंशन समाप्त होने पर मैसेज API से लौटना बंद हो जाते हैं। एक प्रति-घंटा स्वीप बैकग्राउंड में डिलीशन प्रोसेस करता है; भौतिक क्लीनअप API एक्सपायरी से पीछे रह सकता है।

टियर घटाना रीड्स पर तुरंत प्रभावी होता है: नई कटऑफ़ से पुराना कुछ भी तुरंत लौटना बंद हो जाता है। आपके पास इसे पलटने के लिए दस मिनट हैं, और दस मिनट ही एकमात्र गारंटी है: उस विंडो के भीतर टियर फिर से बढ़ा दें तो कुछ नहीं खोता। उसके बाद फँसे हुए मैसेज डिलीशन के लिए पात्र हो जाते हैं और अगला प्रति-घंटा स्वीप उन्हें ले जाता है, इसलिए बाद में टियर बढ़ाने पर केवल वही बचता है जो स्वीप ने अभी तक नहीं लिया।

आपके प्लान में शामिल किसी टियर तक बढ़ाना कभी भी स्वीकार किया जाता है, भले ही पिछला बदलाव अभी लागू हो रहा हो। बैकग्राउंड अपडेट दस-मिनट की पलटने की विंडो से स्वतंत्र है। दूसरी बार घटाना पहले बदलाव द्वारा हर स्टोर्ड मैसेज अपडेट होने के बाद ही स्वीकार किया जाता है। अपडेट हर दस मिनट में शुरू होता है और बड़े मेलबॉक्स के लिए घंटों लग सकता है। पूरा होने तक API E17050 लौटाता है; बाद में फिर से प्रयास करें।

अगर आपका प्लान सीमित मेलबॉक्स स्टोरेज अलाउंस सेट करता है, तो एक अलाउंस हर लाइव या रिस्टोर-योग्य मेलबॉक्स में साझा होता है। हर मेलबॉक्स अपना हिस्सा size_bytes के रूप में रिपोर्ट करता है। सीमित अलाउंस के बिना प्लान में असीमित मेलबॉक्स स्टोरेज होता है। मेलबॉक्स मिलकर सीमित अलाउंस तक पहुँच जाएँ तो भेजना E17049 के साथ अस्वीकार हो जाता है, जब तक आप उनमें से किसी में जगह खाली नहीं करते।

मेलबॉक्स हटाने पर वह तुरंत मेल प्राप्त करना बंद कर देता है। मेलबॉक्स 30 दिन तक रिस्टोर किया जा सकता है, जबकि सामान्य मैसेज-रिटेंशन एक्सपायरी जारी रहती है। 30 दिन बाद स्थायी मिटाना मेलबॉक्स और उसके शेष मैसेज हटा देता है। स्थायी मिटाना शुरू होने के बाद, क्लीनअप जारी होने पर भी रिस्टोर अस्वीकार कर दिया जाता है। पता आपके वर्कस्पेस के लिए आरक्षित बना रहता है।

अगले कदम

अपना पहला मेलबॉक्स क्लेम करें: बनाने से जवाब देने तक का API हैप्पी पाथ।
AI के साथ बनाएँ: MCP सर्वर के ज़रिए एजेंट से मेलबॉक्स चलाएँ।

संबंधित संसाधन