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

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

ज़्यादातर काम दो अंतरों से जुड़ा है। Infobip का पेलोड बल्क भेजने के लिए बना है, इसलिए एक व्यक्ति को एक संदेश भी संदेशों की एक array होता है, जिसमें हर संदेश के पास गंतव्यों की array होती है, और टेक्स्ट दो स्तर नीचे content.text में होता है। POST /v1/sms/messages from, to और text को शीर्ष स्तर पर लेता है। साथ ही, आपका Infobip बेस URL हर खाते के लिए अलग होता है, xxxxx.api.infobip.com के रूप में, और Authorization: App <key> से प्रमाणित होता है। Bird एक क्षेत्रीय होस्ट से bearer कुंजी के साथ भेजता है, इसलिए पेलोड के ढांचे के साथ-साथ आपके कोड में रखा होस्ट भी बदलता है।

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

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

Help me migrate my SMS integration from Infobip 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/infobip.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 Infobip 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 कॉल को मैप करें

नाम बदलने की तालिका छोटी है, क्योंकि असली काम ढांचे को बदलना है:

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

• तीन स्तर, एक भी नहीं रह जाते। यह नेस्टिंग इसलिए है ताकि एक ही अनुरोध में कई संदेश और कई गंतव्य भेजे जा सकें। एक व्यक्ति को एक संदेश भेजते समय Bird तीनों फ़ील्ड शीर्ष स्तर पर लेता है, इसलिए arrays बनाने वाले builder का अनुवाद करने के बजाय उसे हटा दिया जाता है।
• callbackData, metadata से बड़ा है। Infobip 4,000 वर्णों तक स्वीकार करता है और इसे डिलीवरी रिपोर्ट में लौटाता है। Bird का metadata serialize होने पर 2 KB तक सीमित है, और यह संदेश के हर इवेंट पर लौटाया जाता है, सिर्फ़ अंतिम इवेंट पर नहीं। हर इवेंट पर लौटना फ़ायदेमंद है, पर सीमा नहीं। इसलिए सीमा के करीब पहुँचने वाले किसी भी डेटा को पूरा भेजने के बजाय एक ऐसी कुंजी तक छोटा करना होगा जिससे आप उसे खोज सकें।
• campaignReferenceId रिपोर्टिंग संदर्भ है, कैंपेन माइग्रेशन नहीं। Bird के tags {name, value} जोड़े हैं जो क्वेरी डायमेंशन बन जाते हैं, इसलिए आप पहले की तरह कैंपेन के अनुसार एनालिटिक्स बाँट सकते हैं। इनके साथ कोई कैंपेन ऑब्जेक्ट नहीं आता: टैग कोई ब्रॉडकास्ट नहीं बनाता और न ही उसे कॉन्फ़िगर करता है। ऑडियंस कैंपेन ले जाते समय कैंपेन वर्कफ़्लो का अलग से मूल्यांकन करें।
• campaignReferenceId idempotency कुंजी नहीं है। Infobip इसे किसी कैंपेन के प्रदर्शन को ट्रैक करने वाली ID के रूप में परिभाषित करता है, इसलिए यह मैसेज को समूहित करता है, पर डुप्लिकेट नहीं हटाता। अगर आप फिर से प्रयास को सुरक्षित बनाने के लिए इस पर निर्भर थे, तो आप सुरक्षित नहीं थे; यहाँ यह काम Idempotency-Key हेडर करता है।
• category के बराबर कुछ नहीं है। Infobip के मैसेज विकल्प वैधता, डिलीवरी विंडो, फ़्लैश और क्षेत्रीय सेटिंग्स को कवर करते हैं, और इनमें से कोई भी यह नहीं बताता कि मैसेज क्यों भेजा जा रहा है। हर मैसेज प्रकार के लिए तय करें कि वह transactional, marketing, authentication या service है।
• दो विकल्प फ़ील्ड की कोई जगह नहीं है। validityPeriod आरक्षित है और 422 SMSUnsupportedFeature लौटाता है; deliveryTimeWindow का कोई समकक्ष नहीं है, इसलिए शेड्यूलिंग विंडो आपके अपने डिस्पैचर में चली जाती हैं।

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

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

इसलिए इस सेट के सभी प्रोवाइडर में इसका एक्सपोर्ट सबसे आसान है, और विस्तार सबसे बड़ा। Blocklist की एक प्रविष्टि पूरे अकाउंट के लिए एक सब्सक्राइबर है; Bird का एक सप्रेशन एक सेंडर और सब्सक्राइबर का जोड़ा है। इसलिए हर प्रविष्टि उतने सप्रेशन बनती है जितने आपके सेंडर हैं: 1,000 प्रविष्टियों वाली Blocklist और छह सेंडर से 6,000 रिकॉर्ड बनते हैं। शुरू करने से पहले यह गुणक निकाल लें, क्योंकि इसी से तय होता है कि इंपोर्ट एक मिनट में होगा या उसे बैचों और प्रगति लॉग की ज़रूरत होगी।

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

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

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

डिलीवरी स्टेटस का मिलान करें

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

Infobip हर डिलीवरी रिपोर्ट पर एक स्टेटस समूह और एक स्टेटस नाम बताता है, और Bird एक इवेंट प्रकार भेजता है:

EXPIRED वाली पंक्ति पर खास ध्यान दें, क्योंकि Infobip में यह दो अलग चीज़ों को दर्शाती है और यहाँ उनमें से केवल एक ही मौजूद है। Infobip किसी संदेश को तब expire करता है जब उसके अपने प्लेटफ़ॉर्म की वैधता अवधि खत्म हो जाती है, जो डिफ़ॉल्ट रूप से 48 घंटे है, या जब ऑपरेटर अंतिम स्थिति के रूप में expired लौटाता है। Bird अपनी कोई वैधता अवधि तय नहीं करता और संदेश को समाप्त करने वाला कोई टाइमर नहीं चलाता, इसलिए sms.expired केवल कैरियर की डिलीवरी रसीद से ही आता है। ऑपरेटर द्वारा रिपोर्ट किया गया हिस्सा सीधे मैप हो जाता है। प्लेटफ़ॉर्म टाइमर वाले हिस्से का कोई समकक्ष नहीं है, इसलिए जो संदेश उनकी घड़ी के अनुसार expire हो जाता, वह यहाँ तब तक प्रक्रिया में रहता है जब तक कैरियर फ़ैसला न कर ले।

REJECTED जानबूझकर दो बार आता है। Infobip इसका उपयोग उस संदेश के लिए भी करता है जिसे उसने खुद अस्वीकार किया और उस संदेश के लिए भी जिसे ऑपरेटर ने अस्वीकृत के रूप में लौटाया। Bird में ये ऐसे इवेंट हैं जो प्रोसेसिंग या कैरियर के परिणाम और उसके कारण से चुने जाते हैं; कैरियर की अस्वीकृति से sms.rejected बन सकता है। समूह के भीतर का स्टेटस नाम ही इन दोनों में अंतर बताता है, इसलिए जो हैंडलर केवल समूह के आधार पर branch करता था, उसे यहाँ नाम भी देखना होगा। PENDING भी दो पंक्तियों में आता है, क्योंकि स्वीकृति से लेकर अंतिम रिपोर्ट आने तक संदेश इसी समूह में रहता है।

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

• प्रति-संदेश वेबहुक की जगह सब्सक्रिप्शन आते हैं। Infobip हर संदेश पर एक वेबहुक निर्दिष्ट करता है, इसलिए गंतव्य वही चुनता है जो कॉल लिखता है, और content type भी उसी के साथ चुना जाता है। Bird आपके वर्कस्पेस द्वारा पंजीकृत एंडपॉइंट पर JSON भेजता है, और हर एंडपॉइंट अपने चाहे गए इवेंट प्रकारों को सब्सक्राइब करता है। इसलिए दूसरा उपभोक्ता जोड़ने के लिए हर कॉल साइट बदलने के बजाय बस एक और सब्सक्रिप्शन बनाना होता है।
• प्रति-संदेश चुनाव, जिसमें XML भी शामिल है, अब उपलब्ध नहीं है। Infobip में हर संदेश JSON या XML चुन सकता है और 4000 अक्षरों तक का callback डेटा जोड़ सकता है। Bird केवल JSON भेजता है, और callbackData की जगह metadata आता है, जो केवल रिपोर्ट पर नहीं बल्कि उस संदेश के हर इवेंट पर लौटाया जाता है।
• Pull की जगह push आता है। Infobip में आप रिपोर्ट प्राप्त करने के साथ-साथ उन्हें reports एंडपॉइंट से fetch भी कर सकते हैं। Bird में इवेंट के लिए ऐसा कोई poll नहीं है; सब्सक्राइब करें, और ज़रूरत पड़ने पर संदेश की स्थिति API से पढ़ें।

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

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

स्विच करें

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

होस्ट बदलता है, और यह कोड नहीं बल्कि कॉन्फ़िगरेशन का मामला है। आपका Infobip base URL हर खाते के लिए अलग जारी होता है; Bird उस क्षेत्रीय होस्ट से भेजता है जो आपका वर्कस्पेस बनाते समय चुना गया था। स्विच करने से पहले वे सभी जगहें ढूँढें जहाँ होस्ट सेट है, जिनमें environment variables, secrets managers और deploy manifests शामिल हैं। कोई जगह छूट गई तो विफलता build के समय नहीं, बल्कि runtime पर होगी।

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

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

अगले कदम

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

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

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

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

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