Email API: प्रोग्रामेटिक तरीक़े से ईमेल भेजने की पूरी गाइड (2026)

ईमेल API आपके एप्लिकेशन को HTTP अनुरोधों के ज़रिए ईमेल भेजने देता है.

यह सुनने में आसान लगता है, लेकिन इस फ़ैसले का असर प्रोडक्ट की भरोसेमंदी, डिलीवरेबिलिटी, इंजीनियरिंग वर्कफ़्लो, एनालिटिक्स, अनुपालन, ग्राहक अनुभव और सपोर्ट संचालन पर पड़ता है.

इस पेज के पुराने वर्ज़न की रूपरेखा सही थी, लेकिन उसमें पर्याप्त गहराई नहीं थी. उसमें API की तुलना थी, Brevo का एक छोटा उदाहरण था, और यह बताया गया था कि API बनाम SMTP कब इस्तेमाल करें. यह अपडेट उसी ढांचे को बनाए रखता है और उसे एक पूरी, शोध पर आधारित इम्प्लीमेंटेशन गाइड में बदल देता है, जिसमें Brevo, SendGrid, Mailgun, Amazon SES, Postmark के मौजूदा दस्तावेज़ और प्राइसिंग पेज तथा Tajo के अपने मैसेजिंग API दस्तावेज़ इस्तेमाल किए गए हैं.

छोटा जवाब

ईमेल API तब इस्तेमाल करें जब आपको एप्लिकेशन से ट्रिगर होने वाला ईमेल चाहिए:

• साइन अप वेरिफ़िकेशन.
• पासवर्ड रीसेट.
• मैजिक लिंक लॉगिन.
• ऑर्डर कन्फ़र्मेशन.
• शिपिंग सूचना.
• इनवॉइस या रसीद.
• प्रोडक्ट इनवाइट.
• ट्रायल ऑनबोर्डिंग.
• इस्तेमाल से जुड़ा अलर्ट.
• भुगतान फ़ेल होने की सूचना.
• रिन्यूअल रिमाइंडर.
• प्रोडक्ट इवेंट पर आधारित लाइफ़साइकल ऑटोमेशन.

SMTP तब इस्तेमाल करें जब भेजने वाला सिस्टम सिर्फ़ SMTP क्रेडेंशियल सपोर्ट करता हो, या जब आपको किसी पुराने ऐप, प्लगइन, सर्वर या आंतरिक टूल के लिए मानक मेल ट्रांसपोर्ट लेयर चाहिए हो.

सबसे अच्छा ईमेल API आपके स्टैक पर निर्भर करता है:

सिर्फ़ दिखाई देने वाली क़ीमत के आधार पर न चुनें. ईमेल API की लागत में इंजीनियरिंग का समय, डिलीवरेबिलिटी का काम, डेटा मॉडलिंग, निगरानी, सपोर्ट और आगे माइग्रेशन का जोखिम भी शामिल है.

ईमेल API बनाम SMTP

API और SMTP, दोनों ईमेल भेज सकते हैं. फ़र्क़ यह है कि आपका एप्लिकेशन संदेश को भेजने वाले प्लेटफ़ॉर्म तक कैसे पहुंचाता है.

SMTP लंबे समय से चला आ रहा मेल ट्रांसफ़र प्रोटोकॉल है. यह कई टूल के साथ काम करता है और तब भी उपयोगी है जब कोई प्रोडक्ट होस्ट, पोर्ट, यूज़रनेम और पासवर्ड सेटिंग्स मांगता हो.

ईमेल API एक HTTP इंटरफ़ेस है. आपका एप्लिकेशन किसी एंडपॉइंट पर ऑथेंटिकेशन, प्राप्तकर्ता, कंटेंट, टेम्पलेट डेटा, मेटाडेटा और कभी-कभी शेड्यूलिंग या बैच की जानकारी के साथ अनुरोध भेजता है.

व्यावहारिक नियम: अगर एप्लिकेशन कोड आपका है, तो API से शुरू करें. अगर आप कोई ऐसा तीसरे पक्ष का टूल कॉन्फ़िगर कर रहे हैं जो सिर्फ़ SMTP सपोर्ट करता है, तो SMTP इस्तेमाल करें.

ईमेल API कैसे काम करता है

एक बुनियादी सेंड फ़्लो में सात क़दम होते हैं:

1. आपका एप्लिकेशन कोई इवेंट बनाता है, जैसे user_signed_up या order_paid.
2. एप्लिकेशन संदेश का प्रकार चुनता है.
3. एप्लिकेशन प्राप्तकर्ता, भेजने वाले, टेम्पलेट और पर्सनलाइज़ेशन का डेटा लोड करता है.
4. एप्लिकेशन ईमेल प्रोवाइडर को ऑथेंटिकेटेड HTTP अनुरोध भेजता है.
5. प्रोवाइडर अनुरोध की जांच करता है और संदेश को क़तार में लगाता है.
6. प्रोवाइडर सफलता, एरर या मैसेज आइडेंटिफ़ायर के साथ जवाब लौटाता है.
7. Webhook डिलीवरी, बाउंस, क्लिक, शिकायत या अनसब्सक्राइब इवेंट आपके सिस्टम को वापस बताते हैं.

API अनुरोध सिर्फ़ एक हिस्सा है. भरोसेमंद इम्प्लीमेंटेशन के लिए आइडेम्पोटेंसी, री-ट्राई, लॉगिंग, सप्रेशन हैंडलिंग, अलर्टिंग और डेटा गवर्नेंस भी चाहिए.

क्विक स्टार्ट: Brevo API से ईमेल भेजें

Brevo का ट्रांज़ैक्शनल ईमेल API /v3/smtp/email एंडपॉइंट पर ऑथेंटिकेटेड अनुरोध इस्तेमाल करता है. सटीक SDK और फ़ील्ड नाम बदल सकते हैं, इसलिए लागू करते समय वेंडर के API रेफ़रेंस को ही अंतिम स्रोत मानें.

उदाहरण अनुरोध:

curl --request POST \
  --url https://api.brevo.com/v3/smtp/email \
  --header 'api-key: YOUR_API_KEY' \
  --header 'content-type: application/json' \
  --data '{
    "sender": {
      "name": "Your App",
      "email": "[email protected]"
    },
    "to": [
      {
        "email": "[email protected]",
        "name": "Customer"
      }
    ],
    "subject": "Welcome to your account",
    "htmlContent": "<h1>Welcome</h1><p>Your account is ready.</p>"
  }'

प्रोडक्शन कोड में API की हार्ड-कोड नहीं करनी चाहिए. सीक्रेट को सीक्रेट मैनेजर या एनवायरनमेंट वेरिएबल में रखें, उन्हें समय-समय पर बदलें, एक्सेस सीमित रखें, और उन्हें कभी फ़्रंटएंड कोड में उजागर न करें.

प्रोडक्शन ईमेल API आर्किटेक्चर

प्रोडक्शन ईमेल API इंटीग्रेशन को हर कंट्रोलर या रूट हैंडलर से सीधे ईमेल नहीं भेजना चाहिए.

एक छोटी मैसेज लेयर इस्तेमाल करें:

1. कोई प्रोडक्ट इवेंट होता है.
2. एप्लिकेशन उस इवेंट को क़तार, जॉब या इवेंट बस में लिखता है.
3. ईमेल सर्विस उस इवेंट को किसी टेम्पलेट से मैप करती है.
4. ईमेल सर्विस प्राप्तकर्ता की सहमति और सप्रेशन नियमों की जांच करती है.
5. ईमेल सर्विस प्रोवाइडर API को कॉल करती है.
6. ईमेल सर्विस प्रोवाइडर की मैसेज ID दर्ज करती है.
7. Webhook बाद में संदेश की स्थिति अपडेट करते हैं.

इससे प्रोडक्ट कोड साफ़ रहता है और ईमेल की गड़बड़ियां अलग करके पकड़ना आसान हो जाता है.

सुझाए गए आंतरिक फ़ील्ड:

• event_id.
• message_type.
• recipient_id.
• recipient_email.
• template_id.
• locale.
• provider.
• provider_message_id.
• idempotency_key.
• status.
• error_code.
• created_at.
• sent_at.
• delivered_at.

अहम संदेशों के लिए आइडेम्पोटेंसी की इस्तेमाल करें. सिर्फ़ इसलिए तीन पासवर्ड रीसेट ईमेल नहीं जाने चाहिए कि प्रोवाइडर के पहला संदेश स्वीकार करने के बाद नेटवर्क अनुरोध टाइम आउट हो गया.

सबसे अच्छे ईमेल API की तुलना

Brevo

Brevo तब उपयोगी है जब ट्रांज़ैक्शनल ईमेल एक बड़े ग्राहक संवाद सिस्टम का हिस्सा हो.

Brevo तब चुनें जब:

• आपको ट्रांज़ैक्शनल ईमेल के साथ-साथ कैम्पेन, CRM, ऑटोमेशन, SMS या WhatsApp चाहिए.
• ई-कॉमर्स डेटा से लाइफ़साइकल संदेश ट्रिगर होने चाहिए.
• मार्केटिंग और प्रोडक्ट मैसेजिंग को एक ही संपर्क प्रोफ़ाइल साझा करनी है.
• ग़ैर-डेवलपर लोगों को टेम्पलेट और रिपोर्टिंग तक पहुंच चाहिए.
• आप हर चैनल के लिए अलग-अलग टूल के बजाय एक ही प्लेटफ़ॉर्म चाहते हैं.

इन बातों पर ध्यान दें:

• मार्केटिंग ईमेल और ट्रांज़ैक्शनल ईमेल के कॉन्फ़िगरेशन का फ़र्क़.
• इंजीनियरिंग और मार्केटिंग के बीच टेम्पलेट की ज़िम्मेदारी.
• रेट लिमिट और प्लान की पाबंदियां.
• संपर्क डेटा कैसे सिंक होता है.
• अलग-अलग संदेश श्रेणियों पर अनसब्सक्राइब और सप्रेशन नियम कैसे लागू होते हैं.

Brevo के दस्तावेज़ ट्रांज़ैक्शनल सेंडिंग, बैच सेंडिंग, सैंडबॉक्स मोड, SMTP रिले, Webhook, SDK और API रेफ़रेंस पेज कवर करते हैं. इम्प्लीमेंटेशन की बारीकियों के लिए उन्हीं दस्तावेज़ों का इस्तेमाल करें.

SendGrid

SendGrid उन टीमों की आम पसंद है जो व्यापक भाषा और प्लेटफ़ॉर्म सपोर्ट वाला परिपक्व डेवलपर ईमेल API चाहती हैं.

SendGrid तब चुनें जब:

• डेवलपर एक जाना-पहचाना ईमेल API और SDK इकोसिस्टम चाहते हों.
• आपको एक ही वेंडर से ट्रांज़ैक्शनल और मार्केटिंग ईमेल चाहिए.
• आपके पास पहले से Twilio इन्फ़्रास्ट्रक्चर हो.
• आपको इवेंट Webhook और विस्तृत सेंडिंग नियंत्रण चाहिए.

इन बातों पर ध्यान दें:

• चुने गए प्लान में कौन से डिलीवरेबिलिटी और सपोर्ट फ़ीचर शामिल हैं.
• अलग-अलग एनवायरनमेंट में टेम्पलेट कैसे मैनेज होते हैं.
• मार्केटिंग और ट्रांज़ैक्शनल ईमेल को एक ही अकाउंट संरचना साझा करनी चाहिए या नहीं.

Mailgun

Mailgun डेवलपर-नेतृत्व वाली सेंडिंग और API-पहले वाले वर्कफ़्लो के इर्द-गिर्द बना है.

Mailgun तब चुनें जब:

• ईमेल इन्फ़्रास्ट्रक्चर की ज़िम्मेदारी इंजीनियरिंग के पास हो.
• आपको HTTP सेंडिंग, SMTP फ़ॉलबैक, लॉग, इनबाउंड रूट और वैलिडेशन टूल चाहिए.
• आप ऐसा प्रोवाइडर चाहते हैं जो डिलीवरेबिलिटी संचालन को लेकर स्पष्ट हो.

इन बातों पर ध्यान दें:

• कौन से वैलिडेशन, एनालिटिक्स और डिलीवरेबिलिटी फ़ीचर शामिल हैं.
• डेटा रिटेंशन और लॉग तक पहुंच.
• माइग्रेशन और वार्मअप के दौरान सपोर्ट से क्या उम्मीद रखें.

Amazon SES

Amazon SES इन्फ़्रास्ट्रक्चर पर केंद्रित है.

Amazon SES तब चुनें जब:

• आपका एप्लिकेशन पहले से बड़े पैमाने पर AWS पर चलता हो.
• आपके पास ज़्यादा सेटअप ख़ुद संभालने के लिए इंजीनियरिंग संसाधन हों.
• आपको ज़्यादा वॉल्यूम वाली पे-ऐज़-यू-गो सेंडिंग चाहिए.
• आप IAM, CloudWatch, SNS, Lambda या दूसरी AWS सेवाओं के साथ गहरा इंटीग्रेशन चाहते हों.

इन बातों पर ध्यान दें:

• सैंडबॉक्स से बाहर निकलना और प्रोडक्शन एक्सेस.
• डोमेन आइडेंटिटी का सेटअप.
• बाउंस और शिकायत संभालना.
• डेडिकेटेड IP से जुड़े फ़ैसले.
• निगरानी और अलर्टिंग.
• ऐसे फ़ीचर ख़ुद बनाने की इंजीनियरिंग लागत, जो दूसरे प्रोवाइडर अपने प्रोडक्ट UI में देते हैं.

बड़े पैमाने पर SES शानदार हो सकता है, लेकिन यह हर टीम के लिए सबसे कम मेहनत वाला विकल्प नहीं है.

Postmark

Postmark ट्रांज़ैक्शनल ईमेल पर केंद्रित है.

Postmark तब चुनें जब:

• ट्रांज़ैक्शनल भरोसेमंदी और स्पष्टता, ऑल-इन-वन मार्केटिंग की चौड़ाई से ज़्यादा मायने रखती हो.
• आप ऐसी मैसेज स्ट्रीम चाहते हों जो अलग-अलग तरह के ईमेल को अलग रखें.
• आपको एक सीधे-सादे प्रोडक्ट में टेम्पलेट, इनबाउंड ईमेल और डिलीवरी इवेंट चाहिए.

इन बातों पर ध्यान दें:

• आपके वॉल्यूम पर प्राइसिंग टियर.
• आपको इवेंट और मैसेज कितने समय तक रखने चाहिए.
• बल्क मार्केटिंग किसी अलग स्ट्रीम या प्लेटफ़ॉर्म में होनी चाहिए या नहीं.

Tajo

Tajo तब प्रासंगिक है जब ईमेल भेजना ई-कॉमर्स, ग्राहक इवेंट और Brevo से जुड़े ऑटोमेशन से बंधा हो.

Tajo तब इस्तेमाल करें जब:

• प्रोडक्ट और ई-कॉमर्स इवेंट को Brevo में पहुंचाना हो.
• Shopify या दूसरे कॉमर्स डेटा से अबैंडन्ड कार्ट, ऑर्डर या लाइफ़साइकल मैसेजिंग ट्रिगर होनी चाहिए.
• आप ग्राहक, ऑर्डर, प्रोडक्ट और इवेंट डेटा के लिए एक ही इंटीग्रेशन लेयर चाहते हों.
• आपको अपने व्यापक ग्राहक डेटा मॉडल से जुड़ा एक दस्तावेज़ीकृत ट्रांज़ैक्शनल मैसेजिंग रास्ता चाहिए.

Tajo को किसी प्रोवाइडर के अपने API रेफ़रेंस की जगह नहीं लेना चाहिए. इसे सही ग्राहक और इवेंट डेटा मैसेजिंग सिस्टम तक पहुंचाने में लगने वाला इंटीग्रेशन काम कम करना चाहिए.

ईमेल API कब इस्तेमाल करें

ट्रांज़ैक्शनल ईमेल

ट्रांज़ैक्शनल ईमेल किसी यूज़र कार्रवाई या सिस्टम इवेंट से ट्रिगर होते हैं.

उदाहरण:

• अकाउंट वेरिफ़िकेशन.
• मैजिक लिंक लॉगिन.
• पासवर्ड रीसेट.
• टू-फ़ैक्टर ऑथेंटिकेशन.
• प्रोडक्ट इनवाइट.
• ऑर्डर कन्फ़र्मेशन.
• भुगतान की रसीद.
• शिपिंग कन्फ़र्मेशन.
• डिलीवरी अपडेट.
• रिफ़ंड की सूचना.
• सब्सक्रिप्शन रिन्यूअल.
• भुगतान फ़ेल होने का अलर्ट.
• सुरक्षा से जुड़ी सूचना.

ट्रांज़ैक्शनल ईमेल से भरोसेमंदी की उम्मीद बहुत ऊंची होती है. जब लॉगिन लिंक, ऑर्डर की रसीद या पासवर्ड रीसेट नहीं पहुंचता, तो यूज़र को तुरंत पता चल जाता है.

यह भी देखें: ऑर्डर कन्फ़र्मेशन ईमेल और ट्रांज़ैक्शनल ईमेल के उदाहरण.

प्रोडक्ट लाइफ़साइकल ईमेल

लाइफ़साइकल ईमेल ट्रांज़ैक्शनल और मार्केटिंग के बीच में आते हैं.

उदाहरण:

• ट्रायल ऑनबोर्डिंग.
• फ़ीचर एक्टिवेशन.
• इस्तेमाल का पड़ाव.
• अपग्रेड का सुझाव.
• निष्क्रिय अकाउंट रिमाइंडर.
• कस्टमर सक्सेस चेक-इन.
• रिन्यूअल सीक्वेंस.
• विन-बैक संदेश.

ये ईमेल तब सबसे अच्छे काम करते हैं जब किसी सामान्य कैलेंडर के बजाय प्रोडक्ट डेटा से ट्रिगर हों.

ई-कॉमर्स ईमेल

ई-कॉमर्स टीमों को अक्सर ट्रांज़ैक्शनल और मार्केटिंग, दोनों तरह के ट्रिगर वाले ईमेल चाहिए होते हैं:

• वेलकम ऑफ़र.
• अबैंडन्ड कार्ट.
• ब्राउज़ अबैंडनमेंट.
• फिर से स्टॉक में.
• क़ीमत में गिरावट.
• प्रोडक्ट सुझाव.
• रीप्लेनिशमेंट रिमाइंडर.
• लॉयल्टी अपडेट.
• समीक्षा का अनुरोध.
• VIP अर्ली एक्सेस.

Shopify और Brevo इस्तेमाल करने वाली टीमों के लिए Tajo ऑर्डर, ग्राहक, सहमति, प्रोडक्ट और कार्ट डेटा जोड़ने में मदद कर सकता है, ताकि ये संदेश असली कॉमर्स व्यवहार से ट्रिगर हों.

API के ज़रिए मार्केटिंग ईमेल

मार्केटिंग ईमेल को सिर्फ़ बैच न्यूज़लेटर का काम न समझें.

API से ट्रिगर होने वाली मार्केटिंग इनका सहारा बन सकती है:

• इवेंट पर आधारित सेगमेंटेशन.
• पर्सनलाइज़्ड कैम्पेन.
• ट्रिगर होने वाले ड्रिप सीक्वेंस.
• प्रोडक्ट-नेतृत्व वाली ऑनबोर्डिंग.
• अकाउंट आधारित लाइफ़साइकल यात्राएं.
• ग्राहक व्यवहार से जुड़े ऑटोमेटेड ईमेल.

अनुपालन की शर्तें फिर भी लागू रहती हैं. मार्केटिंग संदेशों के लिए उचित सहमति, ऑप्ट-आउट संभालना और सप्रेशन नियम ज़रूरी हैं.

API के किन ज़रूरी फ़ीचर पर ध्यान दें

ऑथेंटिकेशन और की मैनेजमेंट

एक गंभीर ईमेल API को सुरक्षित API की और स्पष्ट ऑथेंटिकेशन दस्तावेज़ सपोर्ट करने चाहिए.

संचालन से जुड़ी ज़रूरतें:

• हर एनवायरनमेंट के लिए अलग की.
• प्रोडक्शन की तक पहुंच सीमित रखें.
• की समय-समय पर बदलें.
• की कोड के बाहर स्टोर करें.
• की का इस्तेमाल लॉग करें, लेकिन की की वैल्यू लॉग न करें.
• फ़ेल हुए अनुरोधों के डंप से की हटा दें.

टेम्पलेट

टेम्पलेट ट्रांज़ैक्शनल ईमेल को एकरूप रखते हैं.

इन पर ध्यान दें:

• वर्ज़निंग.
• टेस्ट सेंड.
• वेरिएबल.
• फ़ॉलबैक वैल्यू.
• लोकलाइज़ेशन.
• प्रीव्यू रेंडरिंग.
• मंज़ूरी के वर्कफ़्लो.
• स्टेजिंग और प्रोडक्शन के अलग टेम्पलेट.

टेम्पलेट सिर्फ़ डिज़ाइन एसेट नहीं हैं. वे प्रोडक्ट के वादे का हिस्सा हैं. पासवर्ड रीसेट टेम्पलेट, ऑर्डर कन्फ़र्मेशन टेम्पलेट या इनवॉइस टेम्पलेट की समीक्षा उतनी ही गंभीरता से होनी चाहिए जितनी एप्लिकेशन UI की.

Webhook

Webhook सेंडिंग को एक फ़ीडबैक लूप में बदल देते हैं.

इन्हें ट्रैक करें:

• प्रोसेस्ड.
• डिफ़र्ड.
• डिलीवर्ड.
• ओपन, सावधानी के साथ.
• क्लिक, सावधानी के साथ.
• बाउंस्ड.
• ड्रॉप्ड.
• शिकायत.
• अनसब्सक्राइब.

प्रोवाइडर की मैसेज ID स्टोर करें, ताकि Webhook इवेंट को आंतरिक यूज़र और इवेंट से मिलाया जा सके.

सप्रेशन मैनेजमेंट

सप्रेशन संभालना डिलीवरेबिलिटी और अनुपालन की रक्षा करता है.

सिस्टम को इन्हें संभालना चाहिए:

• हार्ड बाउंस.
• शिकायतें.
• अनसब्सक्राइब.
• मैनुअल ब्लॉक.
• अगर आपकी नीति उन्हें बाहर रखती है तो रोल आधारित पते.
• अमान्य संपर्क.
• अकाउंट डिलीट करने या प्राइवेसी से जुड़े अनुरोध.

किसी हमेशा के लिए फ़ेल हो चुके पते पर बार-बार कोशिश करते न रहें, सिर्फ़ इसलिए कि प्रोडक्ट कोड “ईमेल भेजो” को एक बैकग्राउंड काम भर मानता है.

रेट लिमिट और थ्रूपुट

जांचें कि प्रोवाइडर इन्हें कैसे संभालता है:

• API अनुरोध की सीमाएं.
• संदेश थ्रूपुट.
• बैच एंडपॉइंट.
• बर्स्ट लिमिट.
• रोज़ या महीने की प्लान सीमाएं.
• नए अकाउंट का वार्मअप.
• डेडिकेटेड IP का वार्मअप.

चरम स्थितियों की योजना बनाएं. कोई प्रोडक्ट लॉन्च, पासवर्ड रीसेट की घटना, Black Friday सेल या सुरक्षा सूचना, सेंड वॉल्यूम को रोज़ के औसत से कहीं ऊपर ले जा सकती है.

एनालिटिक्स और एक्सपोर्ट

न्यूनतम रिपोर्टिंग:

• भेजे गए.
• डिलीवर हुए.
• बाउंस.
• डिफ़र्ड.
• शिकायतें.
• अनसब्सक्राइब.
• टेम्पलेट का प्रदर्शन.
• प्रोवाइडर के रिस्पॉन्स एरर.
• जहां प्रासंगिक हो, कमाई या कन्वर्ज़न इवेंट.

ओपन और क्लिक को सावधानी से देखें. प्राइवेसी सुरक्षा, इमेज ब्लॉकिंग और बॉट गतिविधि जुड़ाव की मेट्रिक बिगाड़ सकती है. ट्रांज़ैक्शनल ईमेल के लिए अक्सर डिलीवरी और यूज़र की सफल कार्रवाई, ओपन रेट से ज़्यादा मायने रखती है.

इनबाउंड पार्सिंग

इनबाउंड ईमेल तब मायने रखता है जब यूज़र जवाब देते हैं या प्रोडक्ट में कंटेंट भेजते हैं.

इस्तेमाल के मामले:

• सपोर्ट के जवाब.
• ईमेल से टिकट बनाना.
• टिप्पणी का जवाब.
• मंज़ूरी के वर्कफ़्लो.
• फ़ॉरवर्ड की गई रसीदें.
• इनबाउंड लीड कैप्चर.

अगर इनबाउंड पार्सिंग रोडमैप का हिस्सा है, तो ऐसा प्रोवाइडर चुनें जिसके दस्तावेज़, राउटिंग, सुरक्षा नियंत्रण और अटैचमेंट हैंडलिंग साफ़ हों.

ईमेल API के साथ डिलीवरेबिलिटी

API अपने आप डिलीवरेबिलिटी हल नहीं करता.

आपको फिर भी चाहिए:

• SPF.
• DKIM.
• DMARC.
• वेरिफ़ाइड सेंडिंग डोमेन.
• एकरूप सेंडर पहचान.
• साफ़-सुथरी लिस्ट.
• बाउंस संभालना.
• शिकायत संभालना.
• मार्केटिंग संदेशों के लिए साफ़ अनसब्सक्राइब.
• प्रासंगिक कंटेंट.
• उचित भेजने की आवृत्ति.
• निगरानी.

नए डोमेन या IP के लिए धीरे-धीरे वार्मअप करें. कम जोखिम वाले, ज़्यादा जुड़ाव वाले मेल से शुरू करें और प्रतिष्ठा स्थिर होने के साथ वॉल्यूम बढ़ाएं.

जहां संभव हो, संदेश के प्रकार अलग रखें:

• ऑथेंटिकेशन और सुरक्षा.
• रसीदें और ऑर्डर अपडेट.
• प्रोडक्ट लाइफ़साइकल.
• मार्केटिंग.
• बल्क प्रमोशन.

किसी आक्रामक प्रमोशन कैम्पेन को पासवर्ड रीसेट या रसीद की डिलीवरी बिगाड़ने न दें.

एरर हैंडलिंग और री-ट्राई

ईमेल API की गड़बड़ियों को वर्गीकृत किया जाना चाहिए.

इन पर दोबारा कोशिश करें:

• टाइमआउट.
• प्रोवाइडर की अस्थायी गड़बड़ी.
• देर बाद रेट लिमिट.
• नेटवर्क फ़ेल्योर.
• क़तार से जुड़ी अस्थायी समस्या.

इन पर बार-बार कोशिश न करते रहें:

• अमान्य प्राप्तकर्ता पता.
• अनधिकृत API की.
• अमान्य टेम्पलेट ID.
• ज़रूरी फ़ील्ड ग़ायब.
• सप्रेस किया गया प्राप्तकर्ता.
• नीति या अनुपालन से जुड़ी रोक.

एक्सपोनेंशियल बैकऑफ़ इस्तेमाल करें, और जो संदेश दोबारा कोशिश के बाद भी फ़ेल हों उनके लिए डेड-लेटर क़तार रखें.

हर अहम ईमेल के लिए एक संचालन रास्ता होना चाहिए:

• क्या सपोर्ट उसे दोबारा भेज सकता है?
• क्या यूज़र दोबारा उसका अनुरोध कर सकता है?
• क्या इंजीनियरिंग इवेंट का पता लगा सकती है?
• क्या आप प्रोवाइडर का जवाब देख सकते हैं?
• क्या आप साबित कर सकते हैं कि प्रोवाइडर ने उसे स्वीकार किया था?

ईमेल API इम्प्लीमेंटेशन चेकलिस्ट

लॉन्च से पहले इस चेकलिस्ट का इस्तेमाल करें.

1. संदेश के प्रकार और ज़िम्मेदारी तय करें.
2. API प्रोवाइडर और फ़ॉलबैक तरीक़ा चुनें.
3. सेंडर डोमेन वेरिफ़ाई करें.
4. SPF, DKIM और DMARC कॉन्फ़िगर करें.
5. स्टेजिंग और प्रोडक्शन API की बनाएं.
6. सीक्रेट सुरक्षित तरीक़े से स्टोर करें.
7. एक मैसेज सर्विस या एडाप्टर बनाएं.
8. आइडेम्पोटेंसी की जोड़ें.
9. संरचित लॉग जोड़ें.
10. री-ट्राई और डेड-लेटर व्यवहार बनाएं.
11. टेम्पलेट बनाएं.
12. पर्सनलाइज़ेशन और फ़ॉलबैक वैल्यू की QA करें.
13. Webhook कॉन्फ़िगर करें.
14. प्रोवाइडर की मैसेज ID स्टोर करें.
15. बाउंस, शिकायत और अनसब्सक्राइब संभालें.
16. दोबारा भेजने और स्थिति देखने के लिए सपोर्ट टूल बनाएं.
17. एरर दर और डिलीवरी दर पर नज़र रखें.
18. रेट लिमिट और इंसिडेंट प्लेबुक दर्ज करें.

प्रोवाइडर चुनने का स्कोरकार्ड

हर वेंडर को 1 से 5 तक अंक दें:

कई टीमों के लिए सही जवाब “सबसे सस्ता ईमेल API” नहीं होता. सही जवाब वह प्रोवाइडर है जो उन ईमेल प्रकारों के लिए संचालन जोखिम कम करे जिन पर ग्राहक निर्भर हैं.

आम ग़लतियां

इनसे बचें:

• बिखरे हुए एप्लिकेशन कोड से सीधे ईमेल भेजना.
• API की या निजी डेटा वाले पूरे पेलोड लॉग करना.
• हर एरर को अस्थायी मानकर दोबारा कोशिश करते रहना.
• प्रोवाइडर की मैसेज ID को नज़रअंदाज़ करना.
• Webhook तब तक भूल जाना जब तक सपोर्ट न पूछे कि “क्या ईमेल पहुंचा?”
• पासवर्ड रीसेट और बल्क मार्केटिंग को एक ही प्रतिष्ठा रास्ते पर मिला देना.
• हर भाषा के लिए एक ही टेम्पलेट इस्तेमाल करना.
• टेम्पलेट वेरिएबल के लिए फ़ॉलबैक वैल्यू छोड़ देना.
• ओपन को डिलीवरी या ग्राहक सफलता का सबूत मान लेना.
• सोची-समझी नीति के बिना मार्केटिंग अनसब्सक्राइब की तर्क-व्यवस्था को ज़रूरी अकाउंट सुरक्षा संदेशों को दबाने देना.
• प्रोवाइडर की तुलना सिर्फ़ मुफ़्त प्लान के आधार पर करना.
• वार्मअप के बिना ज़्यादा वॉल्यूम पर लॉन्च करना.

शुरुआत कैसे करें

नए इम्प्लीमेंटेशन के लिए सबसे छोटा सुरक्षित रास्ता चुनें:

1. एक ही ट्रांज़ैक्शनल संदेश से शुरू करें, जैसे पासवर्ड रीसेट या ऑर्डर कन्फ़र्मेशन.
2. प्रोडक्ट कोड को एक वेंडर से बांधने के बजाय एक प्रोवाइडर एडाप्टर बनाएं.
3. डोमेन ऑथेंटिकेशन जोड़ें.
4. Webhook से स्थिति ट्रैकिंग जोड़ें.
5. सपोर्ट के लिए दृश्यता जोड़ें.
6. टेम्पलेट और लोकलाइज़ेशन जोड़ें.
7. लाइफ़साइकल और ई-कॉमर्स ऑटोमेशन तक विस्तार करें.

अगर आपकी टीम पहले से मार्केटिंग और CRM के लिए Brevo इस्तेमाल करती है, तो Brevo के ट्रांज़ैक्शनल API से शुरू करें और ज़रूरी इवेंट डेटा मैप करें. अगर आपके प्रोडक्ट को ई-कॉमर्स डेटा Brevo में भेजना है, तो और लाइफ़साइकल मैसेजिंग बनाने से पहले ग्राहक, सहमति, प्रोडक्ट, कार्ट और ऑर्डर इवेंट जोड़ने के लिए Tajo का इस्तेमाल करें.

इसके बजाय SMTP सेटअप के लिए SMTP की पूरी गाइड और मुफ़्त SMTP सर्वर गाइड देखें.

संबंधित गाइड

• ट्रांज़ैक्शनल ईमेल सर्विस गाइड
• ट्रांज़ैक्शनल ईमेल के उदाहरण
• SMTP की पूरी गाइड
• SPF, DKIM और DMARC
• ईमेल ऑटोमेशन गाइड
• Brevo Shopify इंटीग्रेशन