Mandrill से माइग्रेट करें

यह पेज Mandrill (Mailchimp Transactional) के messages/send पेलोड, rejection blacklist और webhooks को Bird से मैप करता है। मुख्य माइग्रेशन गाइड का क्रम से पालन करें, और चरण 1, 3 और 4 के लिए इन मैपिंग का उपयोग करें।

पोर्ट करते समय संरचना के दो बदलाव सबसे अहम हैं। Mandrill सब कुछ एक message ऑब्जेक्ट के अंदर रखता है और अनुरोध के बॉडी में key से प्रमाणीकरण करता है। हम एक सपाट टॉप-लेवल पेलोड और एक मानक Authorization: Bearer हेडर लेते हैं। साथ ही, Mandrill का प्राप्तकर्ता type (हर पते पर एक फ़ील्ड के रूप में to/cc/bcc) हमारे यहाँ अलग-अलग to/cc/bcc arrays बन जाता है।

इसे अपने एजेंट को सौंपें

इसे Claude Code, Cursor या Codex में पेस्ट करें। एजेंट आपकी अपनी रिपॉज़िटरी पर इस पेज के चरण पूरे करता है, और उसके पास पहले से मौजूद Bird माध्यम का उपयोग करता है: अगर MCP सर्वर जुड़ा है तो वह, और अगर CLI इंस्टॉल है और उसमें साइन इन है तो वह।

I am moving an email integration from Mandrill to Bird. Route through it with me.
1. Check what you already have before setting anything up. If Bird's MCP server is connected, use its tools. If the Bird CLI is installed and signed in, use that. Either one is enough, and every step below is an action you take with whichever you have. Only if neither is present, follow https://bird.com/docs/ai/set-up-your-agent.md to set one up and sign me in. Every Bird docs page serves Markdown at its own URL with `.md` appended, so fetch that rather than the HTML.
2. Read https://bird.com/docs/guides/email/migrate/mandrill.md for the payload, suppression and event mapping, and https://bird.com/docs/guides/email/migrate.md for the order the steps go in.
3. Find and list my Mandrill usage in this repository before you change anything: the messages/send and messages/send-template call sites and any SDK wrappers around them, the webhook handler and the URL it is registered at, and every domain I send from. Mandrill authenticates with an API key passed in the request body rather than a header, so tell me every place that key appears in my code: the port changes how I authenticate, not just what I send, and that key is a secret currently sitting in a payload.
4. Register each of those sending domains with Bird and give me the DNS records to publish, following https://bird.com/docs/guides/email/sending-domains.md. Leave every DNS record my current provider uses exactly as it is: Bird's records are published alongside them and both providers authenticate side by side until I switch traffic. Publishing DNS affects mail for the whole domain, so show me the records and let me publish them.
5. Export my rejects from Mandrill and import them into Bird before any production traffic goes through Bird, so my first sends do not reach addresses that already bounced or complained. Read the list through rejects/list, and skip the soft-bounce rows: those are transient failures rather than suppressions, and importing them would suppress addresses that are fine. Show me how many rows you skipped. The Bird import takes one address per request and is idempotent, so a partial re-run is safe. https://bird.com/docs/guides/email/suppressions.md has the reason taxonomy.
6. Port the send call and the webhook handler using the mapping tables on the provider page. Move the API key out of the request body and into the Authorization header as a bearer token while you are there. Bird signs deliveries per Standard Webhooks rather than Mandrill's scheme, so treat verification as a rewrite rather than a URL change: https://bird.com/docs/guides/webhooks.md and https://bird.com/docs/guides/email/events.md.
7. Run my whole integration against Bird's mail sandbox before any production traffic, following https://bird.com/docs/guides/email/testing-sandbox.md. Sandbox sends run the real pipeline without reaching an inbox or touching my sending reputation.
8. Stop and ask me wherever a step needs a decision. Do not point production traffic at Bird until I have seen the sandbox results and replied with the words cut over to Bird. Retiring the Mandrill path is a separate step that comes later: ask me again and wait for me to reply with the words retire the Mandrill path. A reply that agrees without naming what it is authorising is not authorisation. Finish by telling me what is left that only a person can do.

send कॉल को मैप करें

हमारी फ़ील्ड सीमाएँ और डिफ़ॉल्ट मान (प्राप्तकर्ताओं की संख्या, टैग और मेटाडेटा की सीमाएँ) ईमेल भेजना पेज पर दी गई हैं।

पोर्ट करने से जुड़े नोट:

• पेलोड को सपाट करें और ऑथेंटिकेशन बदलें। message रैपर हटा दें (उसकी फ़ील्ड शीर्ष स्तर पर आ जाती हैं) और API कुंजी को बॉडी से निकालकर Authorization हेडर में रखें। key फ़ील्ड का यहाँ कोई समकक्ष नहीं है।
• प्राप्तकर्ताओं को type के आधार पर बाँटें। Mandrill हर प्राप्तकर्ता को पते वाले ऑब्जेक्ट पर to, cc या bcc के रूप में चिह्नित करता है। हम तीन अलग-अलग ऐरे इस्तेमाल करते हैं। पोर्ट करते समय to सूची को उसकी type फ़ील्ड के आधार पर समूहों में बाँटें।
• टैग नाम/मान जोड़े बन जाते हैं। Mandrill के टैग सादी स्ट्रिंग होते हैं ("welcome")। हमारे टैग { name, value } जोड़े होते हैं। एक स्थिर name चुनें, जैसे { "name": "category", "value": "welcome" }, ताकि आपके फ़िल्टर और एनालिटिक्स उसी तरह समूह बनाएँ जैसे आपके Mandrill आँकड़े बनाते थे। metadata सीधे JSON के रूप में पोर्ट हो जाता है।
• संग्रहीत टेम्पलेट पोर्ट हो जाते हैं, एक शर्त के साथ। Mandrill का messages/send-template हमारा template फ़ील्ड बन जाता है (ID या slug से संदर्भित), जिसके मान template.parameters में होते हैं। टेम्पलेट के साथ भेजना देखें। हमारे टेम्पलेट वैरिएबल हर प्राप्तकर्ता के लिए नहीं, बल्कि हर संदेश के लिए होते हैं। इसलिए प्रति-प्राप्तकर्ता merge_vars हर प्राप्तकर्ता के लिए एक बैच प्रविष्टि बन जाते हैं, और हर प्रविष्टि का अपना parameters होता है।
• अटैचमेंट सीधे पोर्ट हो जाते हैं। Mandrill का base64 content हमारा content है। इनलाइन images (जिन्हें HTML में cid: के रूप में संदर्भित किया जाता है) content_id वाली attachments प्रविष्टियाँ बन जाते हैं। अटैचमेंट देखें।

सप्रेशन एक्सपोर्ट करें

Mandrill अनचाहे पतों को अपनी rejection blacklist में रखता है। इसे rejects/list API से निकालें (या Rejection Blacklist व्यू से एक्सपोर्ट करें)। हर प्रविष्टि का एक कारण होता है (hard-bounce, soft-bounce, spam, unsub, custom)। soft-bounce वाली पंक्तियाँ छोड़ दें, क्योंकि वे वास्तविक सप्रेशन नहीं, बल्कि अस्थायी विफलताएँ दर्शाती हैं। बाकी पंक्तियों को इम्पोर्ट लूप से चलाएँ।

वेबहुक इवेंट का अनुवाद करें

Mandrill इवेंट को बैच वाले ऐरे में भेजता है। event मान को Bird की इवेंट शब्दावली से मैप करें:

दो अंतर, जिनके लिए आपको कोड बदलना होगा:

• हमारे यहाँ स्वीकृति दो इवेंट में बँट जाती है। Mandrill में send का अर्थ है कि संदेश सिस्टम में डाल दिया गया, और delivered का अर्थ है कि प्राप्त करने वाले सर्वर ने उसे ले लिया। हम भी यही अंतर करते हैं। फ़र्क केवल हमारी तरफ़ है: हम email.delivered से पहले स्वीकृति (email.accepted) को प्रोसेसिंग (email.processed) से अलग रखते हैं। इसलिए जो हैंडलर केवल send पर निर्भर था, उसे अब दो इवेंट में से एक चुनना होगा।
• इवेंट प्रति प्राप्तकर्ता होते हैं और उनका हस्ताक्षर अलग तरीके से होता है। हमारे डिलीवरी इवेंट में email_id के साथ recipient_id भी होता है, और हर प्राप्तकर्ता की अपनी अलग स्ट्रीम होती है। हम हर अनुरोध में एक इवेंट भेजते हैं और उस पर Standard Webhooks विनिर्देश के अनुसार हस्ताक्षर करते हैं। इसके विपरीत, Mandrill बैच किए गए ऐरे पर X-Mandrill-Signature HMAC से हस्ताक्षर करता है। सत्यापन के लिए वेबहुक और इवेंट देखें।

स्विच करें

मुख्य गाइड में डोमेन और DNS तथा सैंडबॉक्स स्मोक टेस्ट के चरण पूरे करें। ये दोनों किसी भी प्रदाता पर निर्भर नहीं हैं।

अगले कदम

• भेजने वाले डोमेन: पंजीकरण, सत्यापन की प्रक्रिया, और वे DNS रिकॉर्ड जिन्हें आप नई जगह पॉइंट कर रहे हैं
• वेबहुक और इवेंट: एंडपॉइंट सेटअप और Standard Webhooks सत्यापन
• टेस्टिंग सैंडबॉक्स: कटओवर से पहले नए इंटीग्रेशन का स्मोक टेस्ट करें
• सप्रेशन: अपनी इंपोर्ट की गई सूची की पुष्टि करें और जानें कि आगे हम इसे कैसे बनाए रखते हैं