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