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

यह पेज Bandwidth के Messages API, Applications और message callbacks को Bird से मैप करता है। मुख्य माइग्रेशन गाइड का क्रम से पालन करें और चरण 3, 4 और 5 के लिए इन मैपिंग का उपयोग करें।

दो अंतर पूरे पोर्ट को प्रभावित करते हैं। Bandwidth चैनल को दो होस्ट पर बाँटता है: भेजना messaging होस्ट पर आपके account path के अंतर्गत होता है और HTTP Basic से प्रमाणित होता है, जबकि 10DLC पंजीकरण मुख्य API होस्ट पर होता है। Bird भेजने, पंजीकरण और delivery events को एक ही base URL और एक ही bearer कुंजी के अंतर्गत रखता है। साथ ही, हर Bandwidth send पर applicationId callback कॉन्फ़िगरेशन ले जाता है; Bird में इसके समकक्ष कोई ऑब्जेक्ट नहीं है, क्योंकि callbacks संदेश की प्रॉपर्टी नहीं, बल्कि वर्कस्पेस की सब्सक्रिप्शन होते हैं।

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

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

Help me migrate my SMS integration from Bandwidth 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/bandwidth.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 Bandwidth 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.

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

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

• to एक ऐरे से घटकर एक प्राप्तकर्ता रह जाता है। Bandwidth एक सूची लेता है, जबकि Bird हर अनुरोध में एक संदेश भेजता है। ऐरे की जगह एक लूप आता है, और हर कॉल अपना Idempotency-Key ले जा सकती है।
• applicationId कहीं और नहीं जाता, बल्कि हट जाता है। इसका काम Bandwidth को यह बताना है कि कॉलबैक कहाँ पोस्ट करने हैं। Bird पर यह एक वर्कस्पेस सब्सक्रिप्शन है, इसलिए भेजने के अनुरोध में इसका नाम कहीं नहीं आता।
• tag और tags एक ही फ़ील्ड नहीं हैं। Bandwidth का tag एक फ़्री-फ़ॉर्म स्ट्रिंग है, जबकि Bird के tags {name, value} जोड़े हैं, जो क्वेरी डायमेंशन बनते हैं। एक अपारदर्शी स्ट्रिंग को आम तौर पर metadata में रखना बेहतर होता है।
• Messages API में ऐसा कुछ नहीं है जो category से मेल खाए। हर संदेश प्रकार के लिए तय करें कि वह transactional, marketing, authentication या service है।

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

निर्यात करने के लिए कोई सूची नहीं है। यह इस गाइड में कोई कमी नहीं, बल्कि खुद एक निष्कर्ष है।

टोल-फ़्री को छोड़कर, Bandwidth आपके लिए opt-in या opt-out सूचियाँ नहीं रखता। उनका अपना मार्गदर्शन यह साफ़ कहता है कि कमांड का पालन करने और सूचियाँ बनाए रखने की ज़िम्मेदारी ग्राहक की है। टोल-फ़्री अपवाद है: वहाँ STOP और उसके रूप आपके कॉन्फ़िगरेशन से स्वतंत्र, नेटवर्क स्तर पर लागू होते हैं। लॉन्ग कोड और शॉर्ट कोड को ऐसी कोई सुविधा नहीं मिलती।

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

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

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

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

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

इस तालिका की दो बातों पर आपको कार्रवाई करनी होगी।

टर्मिनल स्थिति की हैंडलिंग को Bird के मैसेज रिकॉर्ड और इवेंट टाइमस्टैम्प के आधार पर दोबारा बनाएँ। वेबहुक डिलीवरी दोहराई जा सकती हैं या क्रम से बाहर आ सकती हैं। आपका कंज्यूमर यह मानकर न चले कि एक अंतिम कॉलबैक एक ही बार डिलीवर होगा। अस्वीकृत स्थिति और डिलीवरी-विफल स्थिति अलग-अलग Bird इवेंट चुन सकती हैं, भले ही दोनों डाउनस्ट्रीम से आई हों।

message-sending की कोई पंक्ति नहीं है, क्योंकि यह केवल MMS के लिए है, और message-read केवल RBM के लिए है। इनमें से कोई भी SMS के लिए ट्रिगर नहीं होता।

नामों के साथ दो प्रक्रियाएँ भी बदलती हैं:

• Application की जगह सब्सक्रिप्शन ले लेते हैं। Bandwidth कॉलबैक को उस applicationId के आधार पर भेजता है जिसका नाम संदेश में दिया गया था। Bird उन एंडपॉइंट पर डिलीवर करता है जिन्हें आपका वर्कस्पेस रजिस्टर करता है। हर एंडपॉइंट उन्हीं इवेंट प्रकारों को सब्सक्राइब करता है जो उसे चाहिए। इसलिए नए कंज़्यूमर के लिए नया सब्सक्रिप्शन बनाना होता है, नया Application और दोबारा डिप्लॉय नहीं।
• उनके कॉलबैक ऑथेंटिकेशन की जगह Standard Webhooks आता है। Bird Standard Webhooks के अनुसार साइन किए गए JSON भेजता है। अपने सत्यापन को Webhooks और इवेंट में दी गई विधि से बदलें।

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

कटओवर करें

गंतव्य, सेंडर और ट्रैफ़िक रैंप किसी प्रोवाइडर पर निर्भर नहीं हैं और मुख्य गाइड में शामिल हैं। कटओवर योजना में Bandwidth से जुड़ी दो बातें शामिल करें। पहली, आपका 10DLC ब्रांड और कैंपेन Bandwidth के ज़रिए The Campaign Registry में रजिस्टर हैं और अपने-आप Bird रजिस्ट्रेशन नहीं बन जाते। सशुल्क काम सबमिट करने से पहले लागू माइग्रेशन या रजिस्ट्रेशन प्रक्रिया की पुष्टि करें। दूसरी, Bandwidth पर आपके स्वामित्व वाले नंबरों के लिए पोर्ट चाहिए, जिसे सपोर्ट टीम अपने शेड्यूल पर व्यवस्थित करती है, आपके शेड्यूल पर नहीं।

Bird की ओर की आवश्यकताओं के लिए 10DLC के लिए रजिस्टर करें से शुरू करें। इसमें हर फ़ील्ड का अर्थ, रजिस्ट्री द्वारा मान्य इकाई प्रकार, और आवश्यकताओं वाला कॉल शामिल है। यह कॉल बताता है कि ब्रांड बनाने से पहले आपको क्या देना है, क्योंकि ब्रांड बनाने पर शुल्क लगता है।

अगले कदम

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

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

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

• SMS इवेंट: वह इवेंट शब्दावली जिस पर आपका कॉलबैक हैंडलर जाएगा

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