Bandwidth से SMS माइग्रेट करें
यह पेज Bandwidth के Messages API, Applications और message callbacks को Bird पर मैप करता है। मुख्य माइग्रेशन गाइड को क्रम से फ़ॉलो करें और इन मैपिंग्स का उपयोग चरण 3, 4 और 5 के लिए करें।
दो अंतर पूरे पोर्ट को आकार देते हैं। Bandwidth चैनल को दो होस्ट में बांटता है: भेजना messaging होस्ट पर आपके account path के अंतर्गत होता है, जो HTTP Basic से प्रमाणित है, जबकि 10DLC रजिस्ट्रेशन मुख्य API होस्ट पर होता है। Bird भेजने, रजिस्ट्रेशन और डिलीवरी events को एक base URL और एक bearer key के अंतर्गत रखता है। और हर Bandwidth send पर applicationId callback कॉन्फ़िगरेशन रखता है; Bird का कोई समकक्ष ऑब्जेक्ट नहीं है, क्योंकि callbacks एक वर्कस्पेस सब्सक्रिप्शन हैं, मैसेज की प्रॉपर्टी नहीं।
यह अपने एजेंट को दें
इस ब्रीफ़ का उपयोग अपने कोडिंग एजेंट में करें। यह डिस्कवरी से शुरू होता है और किसी भी प्रोडक्शन बदलाव से पहले एक समीक्षा-योग्य माइग्रेशन प्लान तैयार करता है।
कोड उदाहरण
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 कॉल मैप करें
| क्या करता है | Bandwidth | Bird |
|---|---|---|
| प्राप्तकर्ता | to (array) | to (प्रति request एक) |
| प्रेषक | from | from |
| बॉडी | text | text |
| Callback रूटिंग | applicationId | नीचे दिए गए delivery events के लिए सब्सक्राइब किया हुआ एक वर्कस्पेस webhook |
| Intent | (कोई नहीं) | category, फ़्री टेक्स्ट पर आवश्यक |
| फ़्री-फ़ॉर्म लेबल | tag (एक string) | metadata; tags केवल तभी जब आप इसे नाम दे सकें |
| राउंड-ट्रिप कॉन्टेक्स्ट | आपका अपना स्टोर, ID से कुंजित | metadata: मनमाना JSON, हर event पर echo किया जाता है |
| डिलीवरी प्राथमिकता | priority | कोई समकक्ष नहीं |
| सुरक्षित फिर से प्रयास | (उनके specification में नहीं) | Idempotency-Key हेडर |
| मीडिया | media | कोई समकक्ष नहीं: media_urls अस्वीकार किया जाता है |
पोर्टिंग नोट्स:
- to array से सिमटकर एक प्राप्तकर्ता हो जाता है। Bandwidth एक लिस्ट लेता है; Bird प्रति request एक मैसेज भेजता है। एक लूप array की जगह लेता है, और हर कॉल अपना खुद का Idempotency-Key रख सकता है।
- applicationId स्थानांतरित होने के बजाय गायब हो जाता है। यह Bandwidth को बताने के लिए होता है कि callbacks कहां पोस्ट करने हैं। Bird पर यह एक वर्कस्पेस सब्सक्रिप्शन है, इसलिए send पर कुछ भी इसे नाम नहीं देता।
- tag और tags एक ही फ़ील्ड नहीं हैं। Bandwidth का tag एक फ़्री-फ़ॉर्म string है; Bird के tags {name, value} जोड़े हैं जो क्वेरी डाइमेंशन बन जाते हैं। एक अपारदर्शी string आमतौर पर metadata में रखना बेहतर होता है।
- Messages API पर कुछ भी category से मेल नहीं खाता। प्रत्येक मैसेज प्रकार के अनुसार तय करें कि यह transactional, marketing, authentication है या service।
Opt-out स्थानांतरित करें
एक्सपोर्ट करने के लिए कोई सूची नहीं है, और यह इस गाइड की कमी नहीं बल्कि निष्कर्ष है।
Toll-free के अलावा, Bandwidth आपके लिए opt-in या opt-out सूचियां नहीं रखता। उनका अपना मार्गदर्शन स्पष्ट रूप से कहता है: कमांड का पालन करने और सूचियां बनाए रखने की ज़िम्मेदारी ग्राहक की है। Toll-free अपवाद है, जहां STOP और इसके वेरिएंट्स आपके कॉन्फ़िगरेशन की परवाह किए बिना नेटवर्क स्तर पर लागू होते हैं; लॉन्ग कोड और शॉर्ट कोड को ऐसी कोई हैंडलिंग नहीं मिलती।
इसलिए इस माइग्रेशन में प्रामाणिक सूची पहले से आपकी है। यह एक टेबल है, किसी कॉन्टैक्ट रिकॉर्ड पर एक फ़्लैग है, या एक जांच है जो आपका send पथ API को कॉल करने से पहले चलाता है, और पहला काम यह तय करना है कि इनमें से कौन प्रामाणिक है, न कि किसी से एक्सपोर्ट मांगना। आपका अपना inbound-message लॉग फ़ॉलबैक है: कुछ opt-out inbound मैसेज के रूप में शुरू हुए, जबकि अन्य सपोर्ट, फ़ॉर्म या किसी अन्य प्राथमिकता चैनल से आए।
फिर suppression loop के माध्यम से इम्पोर्ट करें। एक Bird suppression एक sender-और-subscriber जोड़ा है, इसलिए जिस subscriber को आपने तीन senders पर रोका है वह तीन रिकॉर्ड हैं। Suppressions पढ़ें और प्रबंधित करें में कमांड है, और यह कारण कि मैन्युअल suppression transactional सहित हर कैटेगरी को ब्लॉक करता है।
कटओवर के बाद सूची का मालिक कौन है यह तय करें, क्योंकि यहीं आप कुछ हासिल करते हैं और इसे खो भी सकते हैं। Bird अपने देश-विशिष्ट कैटलॉग से stop कीवर्ड का जवाब देता है, इसलिए एक बार जब आप यहां से भेज रहे हों तो प्लेटफ़ॉर्म आपके लिए suppressions बनाए रखता है: कोई subscriber जो STOP टेक्स्ट करता है, वह आपके एप्लिकेशन के बिना कुछ किए keyword_stop reason वाला एक रिकॉर्ड बनाता है। अगर आपका कोड अपनी सूची रखता है और उसे लागू करता रहता है, तो दोनों में अंतर आ जाता है, और सामान्य लक्षण यह है कि subscriber ने एक तरफ़ फिर से शुरू किया और दूसरी तरफ़ नहीं। ऑडियंस प्राथमिकता के मालिक को स्पष्ट रखें और प्रासंगिक बदलावों को जानबूझकर सिंक्रोनाइज़ करें। केवल sender suppressions वर्कस्पेस-व्यापी प्राथमिकताओं या कीवर्ड कैटलॉग के बाहर के अनुरोधों को कवर नहीं करते। Reasons मर्ज होने के बजाय स्टैक होते हैं, इसलिए जो जोड़ा आपने manual के रूप में इम्पोर्ट किया और जिसने बाद में STOP टेक्स्ट किया, उसके पास दो रिकॉर्ड होते हैं, और जब तक दोनों समाप्त नहीं हो जाते मैसेज रुके रहते हैं।
डिलीवरी स्टेटस ट्रांसलेट करें
इस टेबल का उपयोग लाइफ़साइकल अवधारणाओं की तुलना करने के लिए करें, events का यांत्रिक रूप से नाम बदलने के लिए नहीं। Bird रिपोर्ट किए गए स्टेटस और reason से failure event चुनता है। एक अस्वीकृत API request कोई मैसेज नहीं बनाता; स्वीकृति के बाद rejection sms.rejected उत्पन्न कर सकता है, जिसमें carrier rejection भी शामिल है। डिलीवरी साक्ष्य न होने पर unknown रहता है। अपने normalized outcome के साथ raw provider status और code को सुरक्षित रखें।
| परिणाम | Bandwidth callback प्रकार | Bird |
|---|---|---|
| API ने मैसेज स्वीकार किया | 202 response, कोई event नहीं | sms.accepted |
| Carrier को सौंपा गया | message-sent | sms.sent |
| Carrier ने डिलीवरी की पुष्टि की | message-delivered | sms.delivered |
| Carrier तक कभी नहीं पहुंचा | message-failed | sms.rejected |
| Carrier ने अस्वीकार किया | message-failed | sms.failed |
| Carrier ने non-delivery रिपोर्ट की | message-failed | sms.undelivered |
| Carrier ने हार मान ली | message-failed | sms.expired |
| प्रवेश पर request अस्वीकृत | request error | HTTP error; कोई मैसेज या event नहीं |
उस टेबल में दो बातें ऐसी हैं जिन पर ध्यान देकर कार्रवाई करनी चाहिए, नज़रअंदाज़ नहीं करनी चाहिए।
Bird के message record और event timestamps के आधार पर terminal-state हैंडलिंग फिर से बनाएं। Webhook डिलीवरी दोहराई जा सकती हैं या क्रम से बाहर आ सकती हैं; आपके consumer को एक अंतिम callback की एक डिलीवरी मानकर नहीं चलना चाहिए। एक rejected स्टेटस और एक delivery-failed स्टेटस अलग-अलग Bird events चुन सकते हैं, भले ही दोनों downstream से उत्पन्न हुए हों।
message-sending की कोई पंक्ति नहीं है क्योंकि यह केवल MMS के लिए है, और message-read केवल RBM के लिए है; दोनों में से कोई भी SMS के लिए फ़ायर नहीं होता।
नामों के साथ दो मैकेनिक्स बदलते हैं:
- Subscriptions Application की जगह लेते हैं। Bandwidth callbacks को उस applicationId के अनुसार रूट करता है जिसे मैसेज ने नाम दिया। Bird उन endpoints पर डिलीवर करता है जो आपका वर्कस्पेस रजिस्टर करता है, प्रत्येक अपनी इच्छित event प्रकारों के लिए सब्सक्राइब किया हुआ, इसलिए एक नया consumer एक नया subscription है, न कि एक नया Application और एक redeploy।
- Standard Webhooks उनकी callback authentication की जगह लेता है। Bird Standard Webhooks के अनुसार साइन किए हुए JSON भेजता है; सत्यापन को Webhooks & events में दी गई विधि से बदलें।
Endpoint एक बार रजिस्टर करें, उन event प्रकारों को नाम दें जो आपका handler चाहता है: ऊपर दिए गए sms.* events सब्सक्राइब करने की सूची हैं, और उनकी जगह लेने वाला कोई wildcard नहीं है। Endpoint बनाएं में कमांड है और पहली कॉल पर सही करने वाली एक बात है, जो signing secret को स्टोर करना है जो response केवल एक बार दिखाता है।
कटओवर करें
Destinations, senders, और ट्रैफ़िक रैंप प्रोवाइडर-स्वतंत्र हैं और मुख्य गाइड में शामिल हैं। दो Bandwidth-विशिष्ट आइटम कटओवर प्लान में होने चाहिए: आपके 10DLC ब्रैंड और कैंपेन Bandwidth के माध्यम से The Campaign Registry के साथ रजिस्टर्ड हैं और स्वचालित रूप से Bird रजिस्ट्रेशन नहीं बन जाते। पेड काम सबमिट करने से पहले लागू माइग्रेशन या रजिस्ट्रेशन प्रक्रिया की पुष्टि करें। Bandwidth पर आपके मालिकाना नंबरों को एक पोर्ट की ज़रूरत है जो सपोर्ट व्यवस्थित करता है, आपके शेड्यूल पर नहीं बल्कि उनके शेड्यूल पर।
Bird-साइड आवश्यकताओं के लिए 10DLC के लिए रजिस्टर करें से शुरू करें: इसमें बताया गया है कि हर फ़ील्ड का क्या अर्थ है, रजिस्ट्री कौन-से entity प्रकार पहचानती है, और वह requirements कॉल जो आपको बताती है कि ब्रैंड बनाने से पहले क्या देना है, जो शुल्क-योग्य चरण है।
अगले कदम
-
SMS के लिए Bird और Bandwidth की तुलना करें: उत्पाद मूल्यांकन और माइग्रेशन विचार
-
SMS भेजना: वह पेलोड जिस पर आप पोर्ट कर रहे हैं, पूर्ण रूप में
-
Opt-outs और keywords: देश के अनुसार keyword कवरेज और suppression प्रबंधन
-
SMS events: वह event शब्दावली जिस पर आपका callback handler जाता है
-
Webhooks & events: endpoint सेटअप और Standard Webhooks सत्यापन
संबंधित संसाधन
इस विषय के लिए डॉक्यूमेंटेशन, गाइड और उदाहरणों के साथ आगे बढ़ें। संसाधन अंग्रेज़ी में हैं।