किसी अन्य प्रोवाइडर से माइग्रेट करें

प्रोडक्शन ईमेल को किसी अन्य प्रोवाइडर से यहाँ लाने के लिए इस गाइड का उपयोग करें। Send रिक्वेस्ट मैप करें, DNS रिकॉर्ड पब्लिश करें, suppressions इम्पोर्ट करें, webhook इवेंट ट्रांसलेट करें, और प्रोडक्शन ट्रैफ़िक Bird पर भेजने से पहले इंटीग्रेशन टेस्ट करें।

माइग्रेशन चेकलिस्ट:

POST /v1/email/messages पर अपनी send कॉल मैप करें
अपने sending डोमेन और DNS री-पॉइंट करें
अपनी suppression सूची इम्पोर्ट करें
Webhooks को हमारी इवेंट शब्दावली में स्विच करें
कटओवर से पहले मेल sandbox के विरुद्ध सत्यापन करें

चरण 1, 3, और 4 इस पर निर्भर करते हैं कि आप किस प्रोवाइडर से आ रहे हैं। आपकी प्रोवाइडर गाइड में फ़ील्ड-दर-फ़ील्ड पेलोड मैपिंग, suppression सूची एक्सपोर्ट करने का तरीका, और webhook इवेंट-नाम ट्रांसलेशन टेबल है।

1. Send कॉल मैप करें

हमारे पास एक single-send endpoint है, POST /v1/email/messages। आप एक फ़्लैट JSON पेलोड बनाते हैं (कोई personalizations wrapper नहीं, कोई MIME असेंबली नहीं) जिसमें from, to/cc/bcc arrays, subject, html और/या text, एक वैकल्पिक reply_to सूची, और कस्टम ईमेल हेडर के लिए headers होते हैं। सफल send em_-प्रीफ़िक्स्ड मैसेज ID के साथ 202 Accepted लौटाता है। डिलीवरी परिणाम webhooks और read endpoints के ज़रिए asynchronously आते हैं। पूरा पेलोड, हर फ़ील्ड की सीमा और डिफ़ॉल्ट सहित, ईमेल भेजना में है। आपके वर्तमान पेलोड से फ़ील्ड-दर-फ़ील्ड मैपिंग आपकी प्रोवाइडर गाइड में है। यदि आपका एप्लिकेशन आज SMTP पर सबमिट करता है, तो आपको कॉल पोर्ट करने की ज़रूरत ही नहीं हो सकती: हम उसी पाइपलाइन में SMTP सबमिशन स्वीकार करते हैं, जिससे यह चरण केवल क्रेडेंशियल स्वैप बन जाता है।

मैसेज सूचियों, एनालिटिक्स, और डैशबोर्ड रोलअप में फ़िल्टर डाइमेंशन के लिए tags का उपयोग करें। metadata का उपयोग स्ट्रक्चर्ड कॉन्टेक्स्ट के लिए करें जिसे Bird मैसेज पर स्टोर करता है, API reads पर लौटाता है, और webhook इवेंट पर echo करता है। सीमाओं के लिए Tags vs metadata देखें।

कोड पोर्ट करने से पहले, इन अंतरों को ध्यान में रखें:

शेड्यूलिंग, स्टोर्ड टेम्प्लेट, और अटैचमेंट सब पोर्ट होते हैं। शेड्यूल्ड सेंडिंग के लिए scheduled_at का उपयोग करें। स्टोर्ड टेम्प्लेट के लिए इनलाइन कंटेंट की जगह template का उपयोग करें। फ़ाइलों को attachments array में मैप करें।
Suppressed प्राप्तकर्ता दृश्य रूप से अस्वीकार किए जाते हैं। एक suppressed पते को फिर भी recipient_id मिलता है और वह मैसेज की प्राप्तकर्ता सूची में rejected स्टेटस और एक email.rejected इवेंट (rejection_reason: recipient_suppressed) के साथ दिखाई देता है, कभी साइलेंट ड्रॉप नहीं। जब हर प्राप्तकर्ता suppressed हो, तब भी रिक्वेस्ट 202 के साथ स्वीकार होती है। हर प्राप्तकर्ता rejected लौटता है। Suppressions देखें।
ऑपरेशनल मेल के लिए category: "transactional" सेट करें। Send डिफ़ॉल्ट रूप से marketing होता है, और category suppression पॉलिसी नियंत्रित करती है: marketing शिकायतों और unsubscribes पर ब्लॉक करता है, transactional उनके बावजूद डिलीवर करता है। न्यूज़लेटर और कैम्पेन डिफ़ॉल्ट से सही ढंग से हैंडल होते हैं। रसीदें, पासवर्ड रीसेट, और इसी तरह के ऑपरेशनल मेल को transactional मार्क करें ताकि वे unsubscribe से अवरुद्ध न हों।

2. डोमेन और DNS री-पॉइंट करें

हर sending डोमेन को POST /v1/email/domains या Email > Domains में रजिस्टर करें, फिर dns_records से रिकॉर्ड पब्लिश करें। DKIM, return-path CNAME, और एक DMARC पॉलिसी sending को गेट करते हैं। एक मौजूदा DMARC रिकॉर्ड, जिसमें पैरेंट डोमेन पर मौजूद रिकॉर्ड भी शामिल है, मान्य है। ट्रैकिंग CNAME केवल ब्रांडेड ओपन और क्लिक ट्रैकिंग को गेट करता है। Sending domains में रिकॉर्ड, सत्यापन लाइफ़साइकल, और रीजनल मॉडल शामिल है। यदि आपका प्रोवाइडर स्प्लिट DKIM वैल्यू चाहता है तो DNS record splitter का उपयोग करें, और यदि आपको पॉलिसी चाहिए तो DMARC policy generator का उपयोग करें।

एक रिकॉर्ड जो अधिकतर प्रोवाइडर आपसे शुरू में बनवाते हैं, जानबूझकर अनुपस्थित है: आप अपने डोमेन apex पर कोई SPF रिकॉर्ड पब्लिश नहीं करते। SPF का मूल्यांकन envelope-from डोमेन के विरुद्ध होता है, जिसे return-path CNAME हमारी ओर पॉइंट करता है, इसलिए SPF आपके apex को छुए बिना पास और अलाइन हो जाता है। यदि आपके पुराने प्रोवाइडर ने आपसे अपने apex SPF रिकॉर्ड में include: जोड़वाया था, तो ट्रांज़िशन के दौरान उसे रहने दें और कटओवर के बाद हटाएँ। यह हमारे ज़रिए भेजे गए मेल को न तो मदद करता है न नुकसान पहुँचाता है, और इसे हटाने से apex SPF द्वारा अनुमत 10 DNS lookups में से एक मुक्त हो जाता है। पूरी व्याख्या DKIM, SPF & DMARC में है।

आप हमारे रिकॉर्ड तब भी पब्लिश कर सकते हैं जब आपके पुराने प्रोवाइडर के रिकॉर्ड अभी लाइव हों। DKIM रिकॉर्ड हमारे एक selector का उपयोग करता है। Return-path और ट्रैकिंग CNAMEs आपके चुने हुए नए hostnames हैं, और आपका मौजूदा DMARC रिकॉर्ड गेट को जैसा-है संतुष्ट करता है। जब तक आप ट्रैफ़िक स्विच करने के लिए तैयार न हों, दोनों प्रोवाइडर साथ-साथ authenticate करते हैं। डोमेन स्टेट रीजनल होता है, इसलिए जिस भी रीजन से भेजते हैं उसमें डोमेन रजिस्टर करें।

3. Suppressions इम्पोर्ट करें

हमारे ज़रिए प्रोडक्शन ट्रैफ़िक भेजने से पहले अपनी suppression सूची ले आएँ। अन्यथा आपके पहले sends उन पतों पर जाएँगे जो आपके पुराने प्रोवाइडर पर पहले ही बाउंस या शिकायत कर चुके हैं, जिससे उस प्रतिष्ठा को नुकसान होगा जिसे आप बचाना चाहते हैं।

अपने वर्तमान प्रोवाइडर से सूची एक्सपोर्ट करें (आपकी प्रोवाइडर गाइड में सटीक endpoints हैं), फिर POST /v1/email/suppressions से हर पता यहाँ जोड़ें:

कोड उदाहरण

while read -r address; do
  curl -s -X POST https://us1.platform.bird.com/v1/email/suppressions \
    -H "Authorization: Bearer $BIRD_API_KEY" \
    -H "Content-Type: application/json" \
    -d "{\"email\": \"$address\"}"
done < suppressions.txt

इस इम्पोर्ट पथ के बारे में दो बातें जानने योग्य हैं:

आप प्रति रिक्वेस्ट एक पता इम्पोर्ट करते हैं। Suppressions API single-entry CRUD है, इसलिए बड़ी सूची का मतलब है एक्सपोर्ट किए गए पतों पर लूप चलाना। कॉल idempotent है (नए रिकॉर्ड के लिए 201, पहले से मैन्युअली suppressed पते के लिए मौजूदा रिकॉर्ड के साथ 200), इसलिए आंशिक इम्पोर्ट दोबारा चलाना सुरक्षित है।
इम्पोर्ट किए गए पतों को reason: manual, applies_to: all मिलता है, जो transactional सहित हर category को ब्लॉक करता है। यह एक native complaint रिकॉर्ड से सख्त है, जो केवल non-transactional sends को ब्लॉक करता है, इसलिए यदि आपको विशिष्ट पतों के लिए category-aware व्यवहार चाहिए, तो Suppressions में reason taxonomy देखें।

आगे आपको bounces खुद मैनेज नहीं करने हैं: हम hard bounces और complaints को ऑटो-suppress करते हैं और email_suppression.created फ़ायर करते हैं ताकि आपके सिस्टम suppression सूची को मिरर कर सकें। Unsubscribes इसके बजाय एक stated preference के रूप में रिकॉर्ड होते हैं, और suppression इवेंट के बजाय email.unsubscribed और email.list_unsubscribed के ज़रिए मिरर होते हैं।

4. Webhooks स्विच करें

POST /v1/webhooks से एक endpoint रजिस्टर करें और इसे इवेंट टाइप की स्पष्ट सूची से सब्सक्राइब करें। हमारे इवेंट नाम resource.action का पालन करते हैं: happy path पर email.accepted → email.processed → email.delivered, और बाकी के लिए email.deferred, email.bounced, email.complained, email.rejected, email.opened, email.clicked, और unsubscribe जोड़ी। आपके वर्तमान प्रोवाइडर की शब्दावली से इवेंट-नाम ट्रांसलेशन आपकी प्रोवाइडर गाइड में है। प्रति-इवेंट पेलोड स्कीमा events reference में हैं।

कोरिलेशन आसानी से पोर्ट होता है। हर इवेंट में email_id, recipient_id, और workspace_id आइडेंटिफ़ायर होते हैं। यह send रिक्वेस्ट से tags और metadata भी echo करता है। इससे वह कॉन्टेक्स्ट मिलता है जो आपका पुराना प्रोवाइडर पेलोड echo के ज़रिए बिना अतिरिक्त lookup के लौटाता था। Send पर अपने इंटरनल IDs metadata में रखें और हर इवेंट से सीधे पढ़ें।

हम Standard Webhooks स्पेसिफ़िकेशन के अनुसार डिलीवरी साइन करते हैं, तीन हेडर का उपयोग करके: webhook-id, webhook-timestamp, और webhook-signature, {id}.{timestamp}.{raw body} पर HMAC-SHA256 के साथ। यदि आप पहले से किसी अन्य प्लेटफ़ॉर्म से Standard Webhooks डिलीवरी सत्यापित करते हैं, तो बिल्कुल वही सत्यापन कोड यहाँ काम करता है। अन्यथा, सत्यापन विधि, फिर से प्रयास करने का शेड्यूल, और replay टूलिंग Webhooks & events में हैं। डिलीवरी at-least-once और unordered होती हैं, इसलिए webhook-id पर deduplicate करें और पेलोड timestamp के अनुसार sort करें, वही अनुशासन जो आपके वर्तमान handler में पहले से होना चाहिए।

5. कटओवर से पहले sandbox में सत्यापन करें

प्रोडक्शन ट्रैफ़िक स्विच करने से पहले, अपना पूरा इंटीग्रेशन (पोर्ट की गई send कॉल, आपका webhook handler, आपकी suppression मिररिंग) मेल sandbox के विरुद्ध चलाएँ। Sandbox sends messagebird.dev पर magic addresses पर जाते हैं और असली प्रोडक्शन पाइपलाइन से गुज़रते हैं: वही 202, वही इवेंट सीक्वेंस, वही signed webhook डिलीवरी, बिना किसी inbox तक पहुँचे या आपकी प्रतिष्ठा को प्रभावित किए।

एक न्यूनतम प्री-कटओवर स्मोक टेस्ट:

delivered@messagebird.dev पर भेजें और सुनिश्चित करें कि आपका handler email.accepted → email.processed → email.delivered प्रोसेस करता है।
bounce@messagebird.dev पर भेजें और सुनिश्चित करें कि आपकी bounce हैंडलिंग email.bounced पर फ़ायर होती है (सिमुलेटेड bounces आपकी suppression सूची में नहीं लिखते, इसलिए पता दोबारा उपयोग योग्य रहता है)।
suppressed@messagebird.dev पर भेजें और सुनिश्चित करें कि आप email.accepted के बाद email.rejected हैंडल करते हैं, उसके बाद कोई email.processed या delivery इवेंट नहीं। यही वह आकार है जो प्रोडक्शन में हर suppressed प्राप्तकर्ता उत्पन्न करता है; rejection_reason: recipient_suppressed विवरण recipient रिकॉर्ड और events API पर होता है।
एक category: "marketing" मैसेज भेजें और पुष्टि करें कि category message read पर वहाँ दिखती है जहाँ आप उम्मीद करते हैं।

टेस्ट केस कोरिलेट करने के लिए +label subaddressing (bounce+cutover-test@messagebird.dev) का उपयोग करें। पूरा पता आपके events में दिखता है। स्मोक टेस्ट पास होने के बाद, ट्रैफ़िक कट ओवर करें। अपने एप्लिकेशन को हमारी ओर पॉइंट करें, और पुराने प्रोवाइडर का DNS तब तक रहने दें जब तक आपके डोमेन यहाँ capabilities.sending verified न दिखाएँ। डैशबोर्ड और अपनी webhook स्ट्रीम में असली डिलीवरी के पहले कुछ घंटे देखें।

किसी विशिष्ट प्रोवाइडर से माइग्रेट करना

SendGrid: personalizations → फ़्लैट पेलोड, categories/custom_args → tags/metadata, dropped ↔ email.rejected समतुल्यता
Mailgun: o:*/v:*/h:* parameters → first-class फ़ील्ड, bounces/complaints/unsubscribes एक्सपोर्ट
Amazon SES: SendEmail v2 → एक endpoint, configuration sets → per-message tracking flags, SNS → signed webhooks
Resend: लगभग समान पेलोड आकार, Svix-signed webhooks → Standard Webhooks
Postmark: comma-separated recipients → arrays, per-stream suppression dumps, unsigned webhooks → signed
Brevo: address objects → plain addresses, दो अलग blocklists एक्सपोर्ट करनी हैं, params → template.parameters
MailerSend: पाँच suppression सूचियाँ जिनमें temporary वाली पीछे रहती है, personalization → per-send parameters
Mailjet: Messages array → एक फ़्लैट पेलोड, EventPayload → metadata, blocklist एक्सपोर्ट
Mandrill: message wrapper और body auth → फ़्लैट पेलोड और bearer auth, rejection blacklist एक्सपोर्ट

अगले चरण

ईमेल भेजना: पूरा send पेलोड, tags vs metadata, async 202 मॉडल
Sending domains: रजिस्ट्रेशन, सत्यापन लाइफ़साइकल, मल्टी-रीजन सेटअप
DKIM, SPF & DMARC: हर रिकॉर्ड क्या साबित करता है, और apex SPF क्यों ज़रूरी नहीं
Suppressions: reasons, categories, और मैनेजमेंट API
Webhooks & events: endpoint सेटअप, Standard Webhooks सत्यापन, retries और replay
Events: प्रति-इवेंट पेलोड स्कीमा
Testing sandbox: पूरी magic-address सूची और walkthroughs
API reference: send endpoint के लिए request और response स्कीमा

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