# MailerSend से माइग्रेशन

यह पेज MailerSend के send पेलोड, suppression सूचियों और webhooks को Bird पर मैप करता है। [मुख्य माइग्रेशन गाइड](/docs/guides/email/migrate) को क्रम से फ़ॉलो करें, और इन मैपिंग्स का उपयोग चरण 1, 3 और 4 के लिए करें।

MailerSend पाँच suppression सूचियाँ रखता है और उनमें से एक डिज़ाइन के अनुसार अस्थायी है। चरण 3 से पहले [Suppressions एक्सपोर्ट करें](#suppressions-एक्सपोर्ट-करें) पढ़ें: उस सूची को इम्पोर्ट करने से 72-घंटे का होल्ड स्थायी ब्लॉक में बदल जाता है।

## अपने एजेंट को यह दें

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

```text
I am moving an email integration from MailerSend 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/mailersend.md for the payload, suppression and webhook mapping, and https://bird.com/docs/guides/email/migrate.md for the order the steps go in.
3. Find and list my MailerSend usage in this repository before you change anything: calls to /v1/email and any SDK wrappers around them, whether I send with template_id and personalization or with html, the webhook handler and the URL it is registered at, and every domain I send from. Tell me the list before you edit anything.
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 MailerSend 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 suppressions 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. MailerSend keeps five lists under /v1/suppressions: hard bounces, spam complaints, unsubscribes and the blocklist are the four to carry over. Do NOT import the On Hold list: it is a temporary 72-hour hold that MailerSend clears by itself, and importing it would suppress those addresses permanently. 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. Both providers sign with HMAC-SHA256, so this is a re-implementation rather than new code: MailerSend sends one Signature header, Bird follows the Standard Webhooks scheme with webhook-id, webhook-timestamp and webhook-signature, and the signed string is constructed differently. Keep the constant-time comparison. 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 MailerSend path is a separate step that comes later: ask me again and wait for me to reply with the words retire the MailerSend 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 कॉल को मैप करें

MailerSend का `POST /v1/email` और हमारा [`POST /v1/email/messages`](/docs/api/reference/create-email-message) एक जैसी संरचना रखते हैं। कोड में बदलने लायक अंतर टैग की सीमा और प्रति-प्राप्तकर्ता डेटा को ले जाने का तरीका है।

| यह क्या करता है    | MailerSend                                                 | Bird                                                  |
| ------------------ | ---------------------------------------------------------- | ----------------------------------------------------- |
| प्रेषक             | `from` (`{email, name}`)                                   | `from`                                                |
| प्राप्तकर्ता       | `to` (अधिकतम 50), `cc` / `bcc` (प्रत्येक अधिकतम 10)        | `to` / `cc` / `bcc` (arrays)                          |
| विषय               | `subject` (अधिकतम 998 कैरेक्टर)                            | `subject`                                             |
| बॉडी               | `html` / `text`                                            | `html` / `text` (कम से कम एक)                         |
| Reply-to           | `reply_to` (`{email, name}`)                               | `reply_to` (array)                                    |
| कस्टम हेडर         | `headers` (`{name, value}`, उच्च प्लान)                    | `headers` (string → string ऑब्जेक्ट)                  |
| फ़िल्टर योग्य लेबल | `tags` (स्ट्रिंग्स का array, अधिकतम 5)                     | `tags`: `{name, value}` जोड़ियाँ                      |
| संग्रहीत टेम्प्लेट | `template_id` + `personalization`                          | `template` + `template.parameters` (नीचे देखें)       |
| अटैचमेंट           | `attachments` (`content`, `filename`, `disposition`, `id`) | `attachments`                                         |
| शेड्यूलिंग         | `send_at` (72 घंटे आगे तक)                                 | `scheduled_at`                                        |
| बल्क प्रीसीडेंस    | `precedence_bulk`                                          | (कोई समकक्ष नहीं, नीचे देखें)                         |
| कैटेगरी            | (कोई नहीं)                                                 | `category`: `marketing` (डिफ़ॉल्ट) या `transactional` |
| थ्रेडिंग           | `in_reply_to`                                              | `headers`                                             |

हमारी फ़ील्ड सीमाएँ और डिफ़ॉल्ट (प्राप्तकर्ता संख्या, टैग और मेटाडेटा सीमाएँ) [ईमेल भेजना](/docs/guides/email/sending-email) में हैं।

पोर्टिंग नोट्स:

- **वहाँ पते ऑब्जेक्ट हैं और यहाँ स्ट्रिंग।** `{"email": "a@x.com", "name": "A"}` बन जाता है `"A <a@x.com>"` या सिर्फ़ `"a@x.com"`, `from`, `to`, `cc`, `bcc` और `reply_to` सभी के लिए।
- **`tags` अधिकतम पाँच वाली सादी स्ट्रिंग्स हैं। हमारे टैग जोड़ियाँ हैं।** `"welcome"` जैसा टैग `{"name": "category", "value": "welcome"}` बन जाता है। एक स्थिर `name` चुनें ताकि आपके डैशबोर्ड उसी तरह फ़िल्टर करें जैसे आपके MailerSend टैग स्टैट्स करते थे।
- **`personalization` प्रति-प्राप्तकर्ता टेम्प्लेट डेटा है।** यह प्राप्तकर्ता ईमेल द्वारा कीड एक array है। हमारा `template.parameters` पूरे send पर लागू होता है, इसलिए जिस मैसेज का कॉन्टेंट वास्तव में प्रति प्राप्तकर्ता अलग है वह प्रति प्राप्तकर्ता एक send या एक [batch](/docs/guides/email/sending-bulk) एंट्री बन जाता है। अगर आपके `personalization` array में हर प्राप्तकर्ता के लिए समान मान हैं, तो वह एक `template.parameters` ऑब्जेक्ट में सिमट जाता है।
- **राउंड-ट्रिप कॉन्टेक्स्ट का कोई MailerSend समकक्ष कॉपी करने के लिए नहीं है।** अगर आप `tags` से कॉन्टेक्स्ट पुनर्निर्मित कर रहे थे, तो इसके बजाय [`metadata`](/docs/guides/email/sending-email) का उपयोग करें: हम इसे हर webhook इवेंट पर `email_id`/`recipient_id` के साथ इको करते हैं, और यह पाँच एंट्री तक सीमित नहीं है।
- **`precedence_bulk` का कोई समकक्ष नहीं है, और `category` वह नहीं है।** `precedence_bulk` एक `Precedence: bulk` हेडर सेट करता है, जो ऑटोरिस्पॉन्डर और आउट-ऑफ़-ऑफ़िस एजेंट्स से चुप रहने का अनुरोध करता है। हमारा `category` तय करता है कि कौन से suppression रिकॉर्ड और अनसब्सक्राइब प्राथमिकताएँ किसी मैसेज को ब्लॉक कर सकती हैं, और कुछ नहीं। उसकी जगह `category` सेट करने से suppression व्यवहार बदलता है और ऑटोरिस्पॉन्डर पर कोई असर नहीं होता। अगर आपको वह हेडर चाहिए, तो ध्यान दें कि `headers` एड्रेसिंग और प्लेटफ़ॉर्म नामों को अस्वीकार करता है लेकिन इसे नहीं।
- **कस्टम हेडर और `list_unsubscribe` MailerSend पर प्लान-गेटेड हैं।** अगर आपके प्लान में ये शामिल नहीं थे, तो यहाँ ये उपलब्ध हैं; [ईमेल भेजना](/docs/guides/email/sending-email) और [कैटेगरी](/docs/guides/email/categories) देखें कि हम मार्केटिंग मेल पर list-unsubscribe कैसे संभालते हैं।

## Suppressions एक्सपोर्ट करें

MailerSend `/v1/suppressions` के अंतर्गत पाँच सूचियाँ रखता है, प्रति सूची एक endpoint। चार स्थायी हैं और ट्रांसफ़र होनी चाहिए; पाँचवीं नहीं होनी चाहिए।

एक्सपोर्ट करें और [इम्पोर्ट लूप](/docs/guides/email/migrate#3-import-suppressions) से गुज़ारें:

- **हार्ड बाउंस**, उदाहरण के लिए `GET https://api.mailersend.com/v1/suppressions/hard-bounces`
- **स्पैम शिकायतें**
- **अनसब्सक्राइब**
- **ब्लॉकलिस्ट**, वे पते और पैटर्न जो आपने मैन्युअली जोड़े

**On Hold सूची इम्पोर्ट न करें।** MailerSend का अपना विवरण यह है कि इसमें ऐसे पते होते हैं जो "have soft bounced 5 times within 30 days", जो "these emails will be blocked for 72 hours", और फिर वे "automatically removed from the list"। यह एक कूलिंग-ऑफ़ अवधि है जिसे प्रोवाइडर खुद क्लियर करता है, इसलिए इसे इम्पोर्ट करने से अस्थायी होल्ड स्थायी suppression में बदल जाता है और चुपचाप उन पतों पर मेलिंग बंद हो जाती है जो रिलीज़ होने वाले थे। इस व्यवहार का हमारा समकक्ष [deferral](/docs/guides/email/events) है, जिसे हम इम्पोर्ट की गई सूची के बजाय लाइव डिलीवरी परिणामों से संभालते हैं।

MailerSend के सूची प्रकार हमारे `hard_bounce`, `complaint`, और `manual` कारणों पर मैप होते हैं; [Suppressions](/docs/guides/email/suppressions) में पूरी वर्गीकरण है।

## Webhook इवेंट्स ट्रांसलेट करें

| परिणाम               | MailerSend                                     | Bird                                             |
| -------------------- | ---------------------------------------------- | ------------------------------------------------ |
| स्वीकृत/प्रोसेस किया | `activity.sent`                                | `email.accepted` → `email.processed`             |
| डिलीवर हुआ           | `activity.delivered`                           | `email.delivered`                                |
| अस्थायी विफलता       | `activity.soft_bounced` / `activity.deferred`  | `email.deferred`                                 |
| स्थायी बाउंस         | `activity.hard_bounced`                        | `email.bounced` / `email.out_of_band_bounce`     |
| स्पैम शिकायत         | `activity.spam_complaint`                      | `email.complained`                               |
| ओपन                  | `activity.opened` / `activity.opened_unique`   | `email.opened`                                   |
| क्लिक                | `activity.clicked` / `activity.clicked_unique` | `email.clicked`                                  |
| अनसब्सक्राइब         | `activity.unsubscribed`                        | `email.unsubscribed` / `email.list_unsubscribed` |
| अस्थायी रूप से होल्ड | `recipient.on_hold_added` / `..._removed`      | (कोई समकक्ष नहीं; ऊपर देखें)                     |

दो अंतर तय करते हैं कि आपके हैंडलर में कितना बदलाव होगा।

**दोनों पक्ष HMAC-SHA256 से साइन करते हैं, इसलिए यह नए कोड के बजाय री-इम्प्लीमेंटेशन है।** MailerSend एक अकेला `Signature` हेडर भेजता है जिसमें उस webhook के साइनिंग सीक्रेट से कंप्यूट किया गया पेलोड का हैश होता है। हम [Standard Webhooks](https://www.standardwebhooks.com) स्कीम फ़ॉलो करते हैं, जो `webhook-id`, `webhook-timestamp` और `webhook-signature` का उपयोग करती है और id, टाइमस्टैम्प और बॉडी से बनी स्ट्रिंग को साइन करती है, इसलिए टाइमस्टैम्प आपको रीप्ले सुरक्षा भी देता है। आपके पास पहले से मौजूद constant-time comparison रखें और construction बदलें; विधि [Webhooks और इवेंट्स](/docs/guides/webhooks) में है।

**MailerSend ओपन और क्लिक को उनके यूनीक वेरिएंट से अलग करता है। हम नहीं करते।** `activity.opened` और `activity.opened_unique` दोनों `email.opened` के रूप में आते हैं, इसलिए जो हैंडलर सिर्फ़ यूनीक वेरिएंट गिनता था उसे `recipient_id` पर खुद डीडुप्लिकेट करना होगा। हमारे डिलीवरी इवेंट्स प्राप्तकर्ता-स्कोप्ड हैं, इसलिए तीन प्राप्तकर्ताओं को भेजा गया send एक के बजाय तीन डिलीवरी परिणाम उत्पन्न करता है।

## कटओवर

मुख्य गाइड में [डोमेन और DNS](/docs/guides/email/migrate#2-re-point-domains-and-dns) और [सैंडबॉक्स स्मोक टेस्ट](/docs/guides/email/migrate#5-verify-in-the-sandbox-before-cutover) पूरे करें। दोनों प्रोवाइडर-स्वतंत्र हैं।

## अगले चरण

- [भेजने वाले डोमेन](/docs/guides/email/sending-domains): रजिस्ट्रेशन, सत्यापन जीवनचक्र, और आप जो DNS रिकॉर्ड प्रकाशित कर रहे हैं
- [Webhooks और इवेंट्स](/docs/guides/webhooks): endpoint सेटअप और Standard Webhooks सत्यापन
- [टेस्टिंग सैंडबॉक्स](/docs/guides/email/testing-sandbox): कटओवर से पहले नए इंटीग्रेशन का स्मोक-टेस्ट करें
- [Suppressions](/docs/guides/email/suppressions): अपनी इम्पोर्ट की गई सूची की पुष्टि करें और हम इसे यहाँ से कैसे मेंटेन करते हैं

## Related resources

- [Getting started with email](/learn/email/getting-started-with-email) (video)
- [Email](/products/email) (product)
- [Build your first integration](/learn/paths/integration) (course)
- [Send your first email](/docs/get-started/send-your-first-email) (docs)

[Get an implementation brief](/learn/workspace?topic=email)