Sinch से SMS पर माइग्रेट करें

यह पेज Sinch के SMS API, ग्रुप और डिलीवरी रिपोर्ट को Bird से मैप करता है। मुख्य माइग्रेशन गाइड का क्रम से पालन करें और चरण 3, 4 और 5 के लिए इन मैपिंग का उपयोग करें।

दो संरचनात्मक अंतर पोर्टिंग को तय करते हैं, और दोनों में फ़ील्ड के नाम बदलने से ज़्यादा मेहनत लगती है। Sinch भेजने के अनुरोध को URL पाथ में दिए गए सर्विस प्लान से जोड़ता है और एक बैच भेजता है, इसलिए एक व्यक्ति को भेजा गया एक संदेश भी एक ऐरे होता है। Bird का POST /v1/sms/messages आपके क्षेत्रीय होस्ट पर बेयरर कुंजी के साथ एक ही प्राप्तकर्ता लेता है, और उसमें प्लान का कोई सेगमेंट नहीं होता। साथ ही, US रजिस्ट्रेशन, जिसे आप छोड़ नहीं सकते, भेजने वाले होस्ट से अलग होस्ट पर और अलग क्रेडेंशियल परिवार के पीछे होता है। इसलिए जो कोडबेस दोनों कामों के लिए Sinch तक पहुँचता है, वह असल में दो जगहों तक पहुँचता है।

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

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

Help me migrate my SMS integration from Sinch to Bird.
1. Inspect this repository's sends, senders, callbacks, schedules, templates, opt-outs and tests. List the traffic and behavior that must survive the migration.
2. Read the Markdown guides at https://bird.com/docs/guides/sms/migrate/sinch.md and https://bird.com/docs/guides/sms/migrate.md. Use an existing authenticated Bird MCP or CLI connection. If neither is available, follow https://bird.com/docs/ai/set-up-your-agent.md. Discover the actual operations; do not invent commands or ask me to paste credentials into chat.
3. Prepare the code changes, sender/destination requirements, consent migration, webhook verification and rollout/rollback plan. Preserve the scope of each customer's preferences, including requests outside SMS replies. Separate API batches from audience broadcasts and preserve any behavior that has no direct endpoint equivalent.
4. Show me the exact affected resources, destinations, test volume and known costs before an action that sends messages, spends money, registers or changes a sender, or moves production traffic. Require explicit human authorization for each paid submission or production change. Name one-off 10DLC registration and resubmission fees before requesting approval. An existing explicit approval for that exact action is sufficient; broad migration approval is not. Simulated SMS destinations are billable and still require authorization.
5. If I am keeping Sinch numbers, prepare the human support port request and obtain authorization to send it. Read bird support-tickets create --help, then use the available CLI or MCP support operation with the reviewed number list and requirements. Return the ticket ID and follow the reply; support arranges the port on its own schedule, separately from the code cutover.
6. Run local and intercepted tests first. When authorized, perform the agreed bounded integration tests, inspect accepted and final outcomes separately, and report failures or uncertainty. Do not claim a delivery receipt proves reading or that request idempotency guarantees exactly-once delivery.
7. Keep production cutover and retiring the old provider as explicit steps in the approved rollout. Finish with the diff, evidence, unresolved requirements and the next action.

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

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

• एकल भेजना, बैच या ब्रॉडकास्ट सोच-समझकर चुनें। Sinch पर to एक array है और यहाँ एक अकेला नंबर, इसलिए एकल भेजने का उपयोग करें या अधिकतम 100 स्वतंत्र संदेशों के लिए बैच endpoint का। ऑडियंस कैंपेन के लिए ब्रॉडकास्ट वर्कफ़्लो सही जगह है। जिस बैच में कोई ग्रुप दिया गया था, उसके लिए पहले ग्रुप की सदस्यता निकालनी होगी; ऑप्ट-आउट वाला सेक्शन देखें, क्योंकि यह वही समस्या है।
• body का नाम text हो जाता है। यही एक नाम-परिवर्तन है जो हर कॉल वाली जगह पर असर डालता है।
• client_reference कोई idempotency कुंजी नहीं है। Sinch इसे बैच की डिलीवरी रिपोर्ट में जोड़े जाने वाले पहचानकर्ता के रूप में परिभाषित करता है, इसलिए यह संदेशों को जोड़कर पहचानने में मदद करता है, पर दोहराव नहीं हटाता। अगर आप फिर से प्रयास को सुरक्षित बनाने के लिए इस पर निर्भर थे, तो आप सुरक्षित नहीं थे; यहाँ यह काम Idempotency-Key करता है।
• category का कोई समकक्ष नहीं है। हर संदेश प्रकार के लिए तय करें कि वह transactional, marketing, authentication या service है।

ऑप्ट-आउट साथ लाएँ

Sinch यह दर्ज करता है कि कौन शामिल है, जबकि Bird को यह जानना होता है कि कौन बाहर है। इसी उलटाव को सँभालना असली काम है।

Sinch प्राप्तकर्ताओं को समूहों के रूप में प्रबंधित करता है, और कोई समूह कीवर्ड ट्रिगर से अपने-आप अपडेट हो सकता है। इसलिए जो सब्सक्राइबर STOP टेक्स्ट करता है, उसे समूह से हटा दिया जाता है, और जो सब्सक्राइबर SUBSCRIBE टेक्स्ट करता है, उसे जोड़ दिया जाता है। इस तरह ऑप्ट-आउट किसी सूची में मौजूद होने के बजाय उससे अनुपस्थित होने के रूप में दर्ज होता है, और अनुपस्थिति को एक्सपोर्ट नहीं किया जा सकता: किसी समूह से गायब नंबर ने ऑप्ट-आउट किया हो सकता है, शायद कभी जुड़ा ही न हो, या छह महीने पहले किसी इंपोर्ट ने उसे हटा दिया हो।

इसलिए एक्सपोर्ट करने के बजाय सूची को दोबारा बनाएँ। आपका अपना इनबाउंड-संदेश लॉग भरोसेमंद स्रोत है, क्योंकि कुछ ऑप्ट-आउट इनबाउंड संदेशों से शुरू हुए, जबकि बाकी सपोर्ट, फ़ॉर्म या किसी अन्य प्राथमिकता चैनल से आए, और समूह की सदस्यता अब जो भी दिखाए, वे संदेश मौजूद रहते हैं। अगर आपने समूह के साथ अपना अनसब्सक्राइब फ़्लैग भी रखा था, तो वह फ़्लैग सदस्यता से बेहतर सबूत है। दोबारा बनाई गई सूची को सप्रेशन लूप में ले जाएँ, और इंपोर्ट करने से पहले सूची खाते के मालिक को दिखाएँ: यहाँ एक गलत प्रविष्टि उन संदेशों को चुपचाप रोक देती है जिन्हें आप भेजना चाहते थे।

Bird में एक सप्रेशन एक सेंडर और सब्सक्राइबर की जोड़ी होता है, इसलिए जिस सब्सक्राइबर को आप तीन सेंडर पर रोकते हैं, उसके तीन रिकॉर्ड बनते हैं। सप्रेशन पढ़ना और प्रबंधित करना में कमांड दी गई है, और यह कारण भी कि मैन्युअल सप्रेशन ट्रांज़ैक्शनल समेत हर श्रेणी को क्यों रोकता है।

माइग्रेशन के बाद Bird हर देश के लिए अपने कैटलॉग से स्टॉप कीवर्ड का जवाब खुद देता है, इसलिए समूह के अपने-आप अपडेट होने वाले व्यवहार को दोबारा बनाने की ज़रूरत नहीं है: जो सब्सक्राइबर STOP टेक्स्ट करता है, उससे आपके एप्लिकेशन के कुछ किए बिना सप्रेशन बन जाता है। कारण आपस में मिलते नहीं, बल्कि एक के ऊपर एक जुड़ते हैं। इसलिए जिस जोड़ी को आपने manual के रूप में इंपोर्ट किया और जो बाद में STOP टेक्स्ट करती है, उसके दो रिकॉर्ड होते हैं, और दोनों खत्म होने तक संदेश रुके रहते हैं।

डिलीवरी स्टेटस का अनुवाद करें

इस तालिका का उपयोग लाइफ़साइकल की अवधारणाओं की तुलना के लिए करें, इवेंट के नाम यांत्रिक रूप से बदलने के लिए नहीं। Bird रिपोर्ट किए गए स्टेटस और कारण के आधार पर विफलता इवेंट चुनता है। अस्वीकार किया गया API अनुरोध कोई संदेश नहीं बनाता; स्वीकृति के बाद हुई अस्वीकृति, जिसमें कैरियर की अस्वीकृति भी शामिल है, sms.rejected बना सकती है। डिलीवरी का सबूत न होने पर नतीजा अज्ञात रहता है। अपने सामान्यीकृत नतीजे के साथ प्रोवाइडर का मूल स्टेटस और कोड भी सुरक्षित रखें।

Sinch के डिलीवरी-रिपोर्ट संदर्भ में queued, dispatched, delivered और कई अलग-अलग अंतिम विफलता स्थितियाँ शामिल हैं। अपनी रिपोर्टिंग का अनुवाद करते समय प्राप्तकर्ता-स्तर का कोड और स्टेटस सुरक्षित रखें।

Bird का sms.expired कैरियर की समाप्ति रिपोर्ट के बाद आता है। हर टाइमआउट को इस इवेंट से जोड़ने के बजाय अपने मौजूदा समाप्ति और रद्दीकरण व्यवहार की अलग से समीक्षा करें।

यह भी ध्यान दें कि मध्यवर्ती स्थितियाँ तभी रिपोर्ट होती हैं जब बैच ने per_recipient रिपोर्टिंग माँगी हो, और यही नीचे बताए गए बदलाव का हिस्सा है।

आप हर भेजे गए संदेश के स्तर पर डिलीवरी रिपोर्टिंग का नियंत्रण खो देते हैं। Sinch बैच अपनी रिपोर्ट की बारीकी खुद चुनता है और केवल उसी भेजने के लिए सर्विस प्लान का कॉलबैक URL बदल सकता है। Bird में इनमें से कुछ नहीं है: रिपोर्टिंग वर्कस्पेस स्तर की सदस्यता है, हर सब्सक्राइब किया गया इवेंट भेजा जाता है, और प्रति-संदेश ओवरराइड नहीं है। अगर आप ज़्यादा संदेश भेजने वाले कैंपेन की रिपोर्टें कम रखने के लिए delivery_report का उपयोग कर रहे थे, तो वह फ़िल्टरिंग आपके हैंडलर में चली जाती है। अगर आप किसी एक कैंपेन की रिपोर्टें अलग एंडपॉइंट पर भेज रहे थे, तो अब एक एंडपॉइंट और एक ब्रांच, या दूसरी सदस्यता का उपयोग करें।

एंडपॉइंट एक बार रजिस्टर करें और उन इवेंट प्रकारों के नाम दें जो आपके हैंडलर को चाहिए: ऊपर दिए गए sms.* इवेंट ही वह सूची हैं जिसे सब्सक्राइब करना है, और उनकी जगह लेने वाला कोई वाइल्डकार्ड नहीं है। Bird Standard Webhooks के अनुसार साइन किए गए JSON भेजता है; एंडपॉइंट बनाएँ में कमांड है, और पहले कॉल में सही करने वाली एक बात भी: प्रतिक्रिया में केवल एक बार दिखने वाला साइनिंग सीक्रेट सहेज लें।

Bird विफलता को मानकीकृत error कोड के साथ रिपोर्ट करता है, जैसे invalid_destination, content_rejected, provider_unavailable या recipient_opted_out; पूरी सूची इवेंट पेज पर है।

कटओवर करें

गंतव्य, सेंडर और ट्रैफ़िक रैंप किसी प्रदाता पर निर्भर नहीं हैं और मुख्य गाइड में बताए गए हैं। कटओवर योजना में Sinch से जुड़े दो काम शामिल करें।

आपका 10DLC ब्रांड और कैंपेन Sinch के ज़रिए The Campaign Registry में पंजीकृत हैं और अपने-आप Bird पंजीकरण नहीं बनते। सशुल्क काम सबमिट करने से पहले लागू माइग्रेशन या पंजीकरण प्रक्रिया की पुष्टि करें। यहीं इंटीग्रेशन सरल भी होता है। Sinch पर पंजीकरण API भेजने वाले होस्ट से अलग होस्ट पर है और सर्विस प्लान टोकन के बजाय प्रोजेक्ट क्रेडेंशियल लेता है। Sinch का अपना दस्तावेज़ बताता है कि वहाँ HTTP Basic केवल परीक्षण के लिए है और उस पर कड़ी दर सीमा लागू है, इसलिए प्रोडक्शन इंटीग्रेशन इसके लिए OAuth टोकन फ़्लो बनाता है। Bird पर /v1/sms/10dlc/* एक ही बेस URL और एक ही कुंजी के तहत /v1/sms/messages के बगल में है, इसलिए उस टोकन लाइफ़साइकल को पोर्ट करने के बजाय हटा दिया जाता है। 10DLC के लिए पंजीकरण करें से शुरू करें। उसमें हर फ़ील्ड का अर्थ बताया गया है, और वह requirements कॉल भी, जो ब्रांड बनाने से पहले बताती है कि आपको क्या देना है। ब्रांड बनाना ही शुल्क वाला चरण है।

Sinch पर आपके अपने नंबरों के लिए पोर्ट ज़रूरी है, जिसे सपोर्ट टीम आपके नहीं, अपने समय के अनुसार व्यवस्थित करती है।

अगले कदम

• SMS के लिए Bird और Sinch की तुलना करें: प्रोडक्ट मूल्यांकन और माइग्रेशन से जुड़ी बातें

• SMS भेजना: वह पेलोड जिस पर आप पोर्ट कर रहे हैं, पूरे विवरण के साथ

• ऑप्ट-आउट और कीवर्ड: हर देश के लिए कीवर्ड कवरेज और सप्रेशन प्रबंधन

• SMS इवेंट: वे इवेंट जिन पर आपका रिपोर्ट हैंडलर जाता है

• वेबहुक और इवेंट: एंडपॉइंट सेटअप और Standard Webhooks सत्यापन