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

यह पेज Postmark के भेजने वाले पेलोड, सप्रेशन डंप और वेबहुक को Bird से मैप करता है। मुख्य माइग्रेशन गाइड को क्रम से अपनाएँ, और चरण 1, 3 और 4 के लिए इन मैपिंग का उपयोग करें।

Postmark के दस्तावेज़ों के अनुसार वह "does not currently support HMAC webhook signature verification" (सितंबर 2026 में पढ़ा गया), इसलिए चरण 4 में ऐसा सत्यापन जुड़ता है जो आपके हैंडलर में अभी नहीं है। कटओवर की योजना बनाने से पहले वेबहुक इवेंट बदलें पढ़ें।

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

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

I am moving an email integration from Postmark 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/postmark.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 Postmark usage in this repository before you change anything: calls to /email and /email/withTemplate and any SDK wrappers around them, every MessageStream name I send on, 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 Postmark 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. Postmark keeps suppressions per message stream, so dump GET /message-streams/{stream_id}/suppressions/dump once for every stream I send on rather than only the default outbound stream. 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. Postmark's docs say it does not currently support HMAC webhook signature verification, so my handler probably has no signature check and adding one is new code rather than a swap. If my registered Postmark webhook URL carries HTTP Basic credentials, take them out and tell me to rotate that pair rather than reusing it on the Bird endpoint: a URL-embedded credential should be treated as exposed. 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 Postmark path is a separate step that comes later: ask me again and wait for me to reply with the words retire the Postmark 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.

भेजने वाली कॉल मैप करें

Postmark भेजने को दो एंडपॉइंट में बाँटता है: तैयार किए गए संदेश के लिए POST /email और सहेजे गए टेम्पलेट के लिए POST /email/withTemplate। हमारा POST /v1/email/messages दोनों के लिए एक ही एंडपॉइंट है, जिसमें टेम्पलेट को एक फ़ील्ड में संदर्भित किया जाता है।

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

पोर्टिंग से जुड़ी बातें:

• Postmark में प्राप्तकर्ता स्ट्रिंग होते हैं और यहाँ ऐरे। "a@x.com, b@x.com" बदलकर ["a@x.com", "b@x.com"] हो जाता है। अगर आपका कोड किसी सूची को जोड़कर वह स्ट्रिंग बनाता है, तो सूची को नहीं, जोड़ने वाले हिस्से को हटाएँ।
• Tag हर संदेश में एक स्ट्रिंग होता है। हमारे tags जोड़े होते हैं, और एक संदेश में कई हो सकते हैं। "welcome" जैसा टैग बदलकर {"name": "category", "value": "welcome"} हो जाता है। एक स्थिर name चुनें, ताकि आपके डैशबोर्ड उसी तरह फ़िल्टर करें जैसे आपके Postmark टैग आँकड़े करते थे।
• Metadata सीधे पोर्ट हो जाता है, और हम उसे वापस भेजते हैं। हम हर webhook इवेंट पर email_id/recipient_id के साथ आपका metadata (और tags) लौटाते हैं, इसलिए आपके हैंडलर को बिना कुछ खोजे आपका संदर्भ वापस मिल जाता है।
• क्लिक ट्रैकिंग वहाँ एक enum है और यहाँ एक boolean। TrackLinks: "None" का मतलब track_clicks: false है; चालू करने वाले तीनों मान track_clicks: true बन जाते हैं, क्योंकि हम HTML और टेक्स्ट भागों को अलग-अलग ट्रैक नहीं करते।
• टेम्पलेट उसी कॉल में आ जाते हैं। टेम्पलेट के लिए कोई अलग endpoint नहीं है: POST /v1/email/messages पर TemplateId या TemplateAlias बदलकर template (ID या slug के ज़रिए) हो जाता है और TemplateModel बदलकर template.parameters हो जाता है। टेम्पलेट के साथ भेजना देखें।
• मैसेज स्ट्रीम का हमारे यहाँ कोई समकक्ष नहीं है, और category उसका समकक्ष नहीं है। स्ट्रीम एक कंटेनर है, जिसकी अपनी सप्रेशन सूची, अपने आँकड़े और अपने webhook होते हैं। हमारी श्रेणी हर संदेश पर लगने वाला एक फ़्लैग है, जिसका एक ही असर होता है: यह तय करती है कि कौन से सप्रेशन रिकॉर्ड और सदस्यता छोड़ने की प्राथमिकताएँ उस संदेश को रोक सकती हैं। ट्रांज़ैक्शनल स्ट्रीम से आए संदेश के लिए category: transactional सेट करना ज़्यादातर मामलों में सही निकलता है। फिर भी यह इस बात का बयान है कि आप संदेश क्यों भेज रहे हैं, स्ट्रीम का पोर्ट नहीं। यहाँ कुछ भी प्रति-स्ट्रीम आँकड़े या प्रति-स्ट्रीम सप्रेशन दायरा नहीं दोहराता; रिपोर्टिंग को बाँटने के लिए टैग इस्तेमाल करें।

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

Postmark सप्रेशन हर मैसेज स्ट्रीम के लिए अलग रखता है, इसलिए पूरे खाते की कोई एक सूची नहीं है जिसे निकाला जा सके। जिस भी स्ट्रीम से आप भेजते हैं, उसकी सूची निकालें और नतीजे को इम्पोर्ट लूप से चलाएँ:

• GET /message-streams/{stream_id}/suppressions/dump

पहले अपनी सभी स्ट्रीम की सूची बनाएँ और जिनसे आप अब भी भेजते हैं, उन सबकी सूची निकालें। अगर आप डिफ़ॉल्ट outbound स्ट्रीम को ही पूरी सूची मान लेते हैं, तो ट्रांज़ैक्शनल सप्रेशन आ जाते हैं पर ब्रॉडकास्ट वाले छूट जाते हैं। इसका पता तब चलता है जब आप उन लोगों को ईमेल भेज देते हैं जिन्होंने ऑप्ट आउट किया था। SuppressionReason के मान HardBounce, SpamComplaint और ManualSuppression हैं, जो हमारे hard_bounce, complaint और manual कारणों से मेल खाते हैं। पूरा वर्गीकरण सप्रेशन में है।

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

Postmark हर इवेंट के लिए एक वेबहुक प्रकार भेजता है और उसे पेलोड के RecordType फ़ील्ड से पहचानता है।

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

सत्यापन के लिए नया कोड लिखना होगा, केवल अदला-बदली काफ़ी नहीं है। Postmark के दस्तावेज़ के अनुसार वह "does not currently support HMAC webhook signature verification" (सितंबर 2026 में पढ़ा गया), और वह पंजीकृत URL में जोड़े गए HTTP Basic क्रेडेंशियल (https://<username>:<password>@example.com/webhook) के साथ आपके फ़ायरवॉल में उसकी IP रेंज जोड़ने की सलाह देता है। हम हर डिलीवरी को Standard Webhooks HMAC योजना के अनुसार साइन करते हैं, इसलिए आपके हैंडलर में सत्यापन का एक नया चरण जुड़ता है। इसका तरीका Webhooks और इवेंट में है। यह चरण सबसे पहले करें: बिना साइन वाले अनुरोध स्वीकार करने वाला हैंडलर माइग्रेशन में आगे नहीं ले जाना चाहिए।

क्रेडेंशियल दोबारा इस्तेमाल न करें, उन्हें बदलें। जो यूज़रनेम और पासवर्ड किसी webhook URL में रहा है, उसे उजागर मानें, क्योंकि URL एक्सेस लॉग, कॉन्फ़िग एक्सपोर्ट और vendor कंसोल तक पहुँचते हैं। उन्हें एंडपॉइंट से हटाएँ, और अगर किसी और चीज़ को अब भी उनकी ज़रूरत है तो नई जोड़ी जारी करें। पुरानी जोड़ी को Bird एंडपॉइंट पर न ले जाएँ, क्योंकि वह इसके बजाय सिग्नेचर से प्रमाणीकरण करता है।

Postmark हार्ड और सॉफ़्ट बाउंस को एक ही Bounce रिकॉर्ड के रूप में रिपोर्ट करता है, जिसमें Type फ़ील्ड होता है। हम उन्हें अलग-अलग इवेंट के रूप में रिपोर्ट करते हैं। जो हैंडलर बाउंस पेलोड के भीतर Type के आधार पर शाखा बनाता है, वह यहाँ इवेंट के नाम के आधार पर शाखा बनाता है: अस्थायी विफलताएँ email.deferred के रूप में आती हैं और स्थायी विफलताएँ email.bounced के रूप में। Postmark जिन बाउंस प्रकारों में अंतर करता है, वे सभी उसके Bounce API संदर्भ में दिए गए हैं; पोर्ट करते समय यह मायने रखता है कि हर प्रकार इस विभाजन के किस तरफ़ आता है।

हमारे डिलीवरी इवेंट हर प्राप्तकर्ता के लिए अलग होते हैं (email_id के साथ recipient_id), इसलिए तीन प्राप्तकर्ताओं को भेजे गए संदेश से एक के बजाय तीन डिलीवरी परिणाम मिलते हैं।

कटओवर करें

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

अगले चरण

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