चेकआउट के बाद आपके एप्लिकेशन के पास एक ऑर्डर होता है और एक प्राप्तकर्ता, जिसे रसीद चाहिए। एप्लिकेशन संदेश सबमिट करने के लिए ईमेल API का उपयोग करता है। वह प्रतिक्रिया को ऑर्डर के साथ दर्ज करता है।
सबमिशन केवल पहला कदम है। आपके एप्लिकेशन को किसी अनुरोध के लिए फिर से प्रयास करने का तरीका भी चाहिए। उसे यह भी पता होना चाहिए कि सबमिशन के बाद संदेश का क्या हुआ।
एप्लिकेशन का कोई इवेंट ईमेल कैसे बनता है?
आपका एप्लिकेशन किसी पूरे हुए लेन-देन या खाता अनुरोध को भेजने की कार्रवाई में बदलता है। सबमिशन के बाद डिलीवरी ईमेल सेवा संभालती है।
रसीद के लिए यह क्रम इस प्रकार है:
- आपका एप्लिकेशन पुष्टि करता है कि ऑर्डर रसीद के लिए तैयार है।
- वह प्राप्तकर्ता चुनता है और ऑर्डर का विवरण सामग्री या टेम्पलेट मानों के रूप में देता है।
- वह संदेश सबमिट करता है और लौटाई गई मैसेज ID को ऑर्डर के साथ सहेजता है।
- डिलीवरी इवेंट आने पर वह भेजने के रिकॉर्ड को अपडेट करता है।
एक ईमेल API ट्रांज़ैक्शनल और मार्केटिंग, दोनों तरह के संदेशों को सपोर्ट कर सकता है। API का उपयोग करने से प्रचार वाली सामग्री ट्रांज़ैक्शनल नहीं बन जाती, और न ही CAN-SPAM के दायित्व हटते हैं।
सफल प्रतिक्रिया का क्या मतलब है?
सबमिशन की सफल प्रतिक्रिया यह दर्ज करती है कि सेवा ने क्या स्वीकार किया। प्राप्त करने वाला मेल सर्वर बाद में जो निर्णय लेता है, वह इससे अलग है।
HTTP के 202 स्टेटस का मतलब है कि अनुरोध को प्रोसेसिंग के लिए स्वीकार कर लिया गया है। प्रोसेसिंग अभी पूरी नहीं हुई है, इसलिए इस प्रतिक्रिया से डिलीवरी साबित नहीं होती।
सटीक प्रतिक्रिया API पर निर्भर करती है। उदाहरण के लिए, Bird का send एंडपॉइंट id के साथ एक कतारबद्ध संदेश लौटाता है। इस ID को ऑर्डर या खाता इवेंट के साथ सहेजें, ताकि बाद के नतीजों को मूल अनुरोध से मिलाया जा सके।
अगर वैलिडेशन विफल होता है, तो Bird 422 लौटाता है, साथ में एक त्रुटि होती है जो बताती है कि अनुरोध क्यों अस्वीकार किया गया।
फिर से प्रयास करने पर डुप्लिकेट संदेशों से कैसे बचा जाता है?
आइडेम्पोटेंसी कुंजी एक तार्किक भेजने की कार्रवाई को सभी फिर से प्रयासों में पहचानती है। जो API इसे सपोर्ट करता है, वह दोहराए गए अनुरोध को पहचान सकता है और नया संदेश नहीं भेजता।
उदाहरण के लिए, ऑर्डर 8472 की रसीद receipt/order-8472 कुंजी का उपयोग कर सकती है। अगर प्रतिक्रिया मिलने से पहले कनेक्शन टूट जाए, तो उसी कुंजी के साथ वही अनुरोध फिर से प्रयास करें।
नई कुंजी एक अलग कार्रवाई को पहचानती है। इसलिए आपके एप्लिकेशन को अपने फिर से प्रयासों और रीस्टार्ट के दौरान मूल कुंजी सुरक्षित रखनी होगी।
आइडेम्पोटेंसी की एक अवधि होती है, जिसे प्रदाता तय करता है। यह अवधि खत्म होने के बाद उसी कुंजी को नए अनुरोध के रूप में प्रोसेस किया जा सकता है।
वेबहुक डिलीवरी की जानकारी कैसे देते हैं?
जब संदेश की स्थिति बदलती है, तब वेबहुक आपके एप्लिकेशन को एक इवेंट भेजता है। इससे आपका एप्लिकेशन शुरुआती API प्रतिक्रिया के बाद भी अपने रिकॉर्ड अपडेट कर सकता है।
Bird के ईमेल इवेंट इन परिणामों में अंतर करते हैं:
| इवेंट | इससे क्या पता चलता है |
|---|---|
email.delivered | प्राप्त करने वाले मेल सर्वर ने संदेश की ज़िम्मेदारी स्वीकार कर ली |
email.deferred | डिलीवरी अस्थायी रूप से विफल हुई है, और इसके लिए फिर से प्रयास किया जाएगा |
email.bounced | प्राप्त करने वाले सर्वर ने डिलीवरी अस्वीकार कर दी |
email.rejected | संदेश डिलीवरी के प्रयास तक नहीं पहुँचा |
सर्वर के स्वीकार कर लेने से यह तय नहीं होता कि संदेश इनबॉक्स में पहुँचा या पढ़ा गया। संदेश स्वीकार करने के बाद भी प्राप्त करने वाला सर्वर बाद में बाउंस की सूचना दे सकता है।
आपके वेबहुक हैंडलर को भेजने वाले के हस्ताक्षर की जाँच करनी होगी और डुप्लिकेट डिलीवरी को संभालना होगा। Bird का वेबहुक अनुबंध webhook-id के आधार पर डुप्लिकेट हटाना अनिवार्य करता है।
टेम्पलेट से क्या बदलता है?
सहेजा गया टेम्पलेट दोबारा इस्तेमाल होने वाली संदेश सामग्री को हर भेजने के लिए दिए जाने वाले मानों से अलग रखता है। आपका एप्लिकेशन पूरा ईमेल बॉडी तैयार किए बिना ऑर्डर नंबर और ग्राहक का नाम दे सकता है।
Bird के टेम्पलेट के साथ, हर भेजने के अनुरोध में एक प्रकाशित टेम्पलेट का नाम और उसके पैरामीटर दिए जाते हैं। विषय और बॉडी टेम्पलेट से आते हैं।
टेम्पलेट यह तय नहीं करता कि ऑर्डर कब पूरा हुआ या पासवर्ड रीसेट अधिकृत है या नहीं। ये निर्णय आपके एप्लिकेशन में ही रहते हैं।
यह SMTP रिले या मार्केटिंग प्लेटफ़ॉर्म से कैसे अलग है?
HTTP API और SMTP रिले संदेश जमा करने के अलग-अलग इंटरफ़ेस हैं। मार्केटिंग प्लेटफ़ॉर्म कैंपेन का काम भी संभालता है, जैसे ऑडियंस चुनना और भेजने का समय तय करना।
| इंटरफ़ेस या प्रोडक्ट | आपका एप्लिकेशन क्या देता है |
|---|---|
| ईमेल API | एक संरचित HTTP अनुरोध, जिसमें प्राप्तकर्ता और सामग्री या टेम्पलेट हों |
| SMTP रिले | प्राप्तकर्ताओं और एक फ़ॉर्मेट किए गए ईमेल संदेश को सबमिट करने वाली SMTP बातचीत |
| मार्केटिंग प्लेटफ़ॉर्म | कैंपेन सामग्री, ऑडियंस का चयन और भेजने के निर्देश |
SMTP किसी संदेश और उसके प्राप्तकर्ताओं को सबमिट करने का आदान-प्रदान परिभाषित करता है। यह ट्रांज़ैक्शनल या मार्केटिंग, दोनों तरह के मेल ले जा सकता है।
Bird का SMTP रिले और HTTP API एक ही डिलीवरी प्रोडक्ट का उपयोग करते हैं, जिसमें इवेंट और सप्रेशन हैंडलिंग शामिल हैं। SMTP चुनने से ये क्षमताएँ हटती नहीं हैं।
Bird के ज़रिए ट्रांज़ैक्शनल ईमेल कैसे भेजें?
आप एक सत्यापित प्रेषक, प्राप्तकर्ताओं और इनलाइन सामग्री या एक प्रकाशित टेम्पलेट के साथ POST /v1/email/messages को कॉल करते हैं। ऑपरेशनल मेल के लिए category: "transactional" सेट करें। प्रतिक्रिया एक मैसेज ID के साथ 202 Accepted होती है; डिलीवरी एसिंक्रोनस रूप से आगे बढ़ती है।
हर लॉजिकल सेंड के लिए एक Idempotency-Key का उपयोग करें। Bird पूरी हो चुकी प्रतिक्रिया को तीन घंटे तक रखता है। उस अवधि के बाद फिर से प्रयास करने पर एक और संदेश बन सकता है, इसलिए पूरे हो चुके बिज़नेस इवेंट का अपना रिकॉर्ड रखें।
ईमेल इवेंट को सब्सक्राइब करें और email_id व recipient_id को अपने रिकॉर्ड से मिलाएँ। कई प्राप्तकर्ताओं वाले संदेश में हर प्राप्तकर्ता का परिणाम अलग होता है।
प्रोवाइडर चुनने के लिए, ट्रांज़ैक्शनल ईमेल सेवा चेकलिस्ट में तुलना करने लायक डिलीवरी और ऑपरेशनल क्षमताएँ दी गई हैं।