Plivo से SMS माइग्रेट करें
यह पेज Plivo के Message API, Powerpacks और डिलीवरी कॉलबैक को Bird पर मैप करता है। मुख्य माइग्रेशन गाइड को क्रम से फ़ॉलो करें और इन मैपिंग का उपयोग स्टेप 3, 4 और 5 के लिए करें।
भेजना आसान हिस्सा है। दोनों JSON लेते हैं जिनमें lowercase फ़ील्ड नाम होते हैं, और दोनों 10DLC रजिस्ट्रेशन को send के साथ रखते हैं, किसी अलग होस्ट पर नहीं। दो चीज़ें बदलती हैं। Plivo का POST https://api.plivo.com/v1/Account/{auth_id}/Message/ Auth ID और Auth Token से HTTP Basic के ज़रिए प्रमाणित करता है; POST /v1/sms/messages आपके रीजनल होस्ट पर bearer API key लेता है, पाथ में कोई account सेगमेंट नहीं होता। और एक Plivo Powerpack नंबर पूल, sticky sender व्यवहार और ऑप्ट-आउट स्टेट को एक ऑब्जेक्ट में बंडल करता है; Bird इन्हें सेंडर, सप्रेशन और कीवर्ड नियमों में बाँटता है, इसलिए Powerpack के रूप में दोबारा बनाने को कुछ नहीं है।
इसे अपने एजेंट को दें
इस ब्रीफ़ का उपयोग अपने कोडिंग एजेंट में करें। यह डिस्कवरी से शुरू होता है और किसी भी प्रोडक्शन बदलाव से पहले एक समीक्षा-योग्य माइग्रेशन प्लान तैयार करता है।
कोड उदाहरण
Help me migrate my SMS integration from Plivo 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/plivo.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 Plivo 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 कॉल को मैप करें
| यह क्या करता है | Plivo | Bird |
|---|---|---|
| प्राप्तकर्ता | dst | to (प्रति रिक्वेस्ट एक) |
| सेंडर | src या powerpack_uuid | from |
| बॉडी | text | text |
| चैनल सिलेक्टर | type: sms, mms, whatsapp | endpoint ख़ुद; /v1/sms/messages है SMS |
| इंटेंट | (कोई नहीं) | category, फ़्री टेक्स्ट पर आवश्यक |
| डिलीवरी रिपोर्ट | url + method, प्रति मैसेज | एक वर्कस्पेस webhook; केवल JSON POST, नीचे देखें |
| राउंड-ट्रिप कॉन्टेक्स्ट | आपका अपना स्टोर, UUID से keyed | metadata: arbitrary JSON, हर इवेंट पर echo होता है |
| फ़िल्टर करने योग्य लेबल | (कोई नहीं) | tags: {name, value} पेयर |
| सुरक्षित रीट्राई | (कोई दस्तावेज़ नहीं) | Idempotency-Key हेडर |
| मीडिया | media_urls | कोई समकक्ष नहीं: media_urls रिजेक्ट होता है |
पोर्टिंग नोट्स:
- Powerpack UUID एक सामान्य sender वैल्यू बन जाता है। Plivo UUID के पीछे नंबर पूल, sticky sender और लोकल प्रेज़ेंस रिज़ॉल्व करता है। Bird सेंडर को सीधे from में लेता है, इसलिए इसे प्रति send चुनें, या टेम्प्लेट send का उपयोग करें, जो गंतव्य के लिए एक वैध sender चुनता है और from को रिजेक्ट करता है।
- type का कोई समकक्ष नहीं है क्योंकि endpoint ख़ुद इसे दर्शाता है। Plivo प्रति रिक्वेस्ट चैनल चुनता है; Bird के SMS, WhatsApp और अन्य चैनल अलग-अलग endpoint हैं। जो कोडबेस रनटाइम पर type स्विच करता है, वह अलग-अलग endpoint कॉल में बँट जाता है।
- Message API पर कुछ भी category से मेल नहीं खाता। प्रति मैसेज टाइप तय करें कि यह transactional, marketing, authentication या service है। विशेष रूप से ऑथेंटिकेशन ट्रैफ़िक को उसी रूप में लेबल किया जाना चाहिए, न कि मार्केटिंग डिफ़ॉल्ट में छोड़ा जाना चाहिए।
- रीट्राई सिमैंटिक्स की अलग से समीक्षा करें। Plivo के send रेफ़रेंस में कोई idempotency key या डीडुप्लिकेशन मेकेनिज़्म दस्तावेज़ित नहीं है, इसलिए वहाँ टाइमआउट आपको अनिश्चित छोड़ता है। पहले पोर्ट से ही Idempotency-Key हेडर भेजें ताकि तीन घंटे की रीप्ले विंडो में डुप्लिकेट रिक्वेस्ट का जोखिम कम हो; यह exactly-once डिलीवरी गारंटी नहीं है।
ऑप्ट-आउट ट्रांसफ़र करें
Plivo की DND सर्विस एक Plivo नंबर से एक गंतव्य पर आउटबाउंड मैसेज तब ब्लॉक करती है जब वह गंतव्य ऑप्ट-आउट कीवर्ड से जवाब देता है। ब्लॉक हुआ send Plivo error code 200 के साथ फ़्लैग होकर लौटता है, जो उनके मैसेज error codes में से एक है, कोई HTTP स्टेटस नहीं, भले ही यह एक जैसा दिखे। यही पेयरिंग Bird सप्रेशन में भी काम करती है: एक सेंडर और एक सब्सक्राइबर, इसलिए इम्पोर्ट के दायरे में उस व्यक्ति के अनुरोध में शामिल हर सेंडर और प्रोग्राम कवर होने चाहिए।
एक चीज़ बढ़ती है, और यही इम्पोर्ट से पहले गिनने की वजह है। US 10DLC कैम्पेन के अंदर, Plivo किसी भी एक नंबर से ऑप्ट-आउट को उस कैम्पेन से जुड़े हर नंबर से ऑप्ट-आउट मानता है। Bird पेयर स्टोर करता है, इसलिए जिस सब्सक्राइबर ने चार-नंबर वाले कैम्पेन से ऑप्ट-आउट किया, वह एक के बजाय चार सप्रेशन बन जाता है। शुरू करने से पहले हिसाब लगाएँ कि आपकी लिस्ट कितने पेयर बनती है, क्योंकि इससे तय होता है कि इम्पोर्ट दसियों का लूप है या हज़ारों का।
लिस्ट निकालना कंसोल एक्सपोर्ट है, API कॉल नहीं: Plivo कंसोल में नंबर फ़िल्टर करें, उन्हें चुनें, और Choose Action मेन्यू से Export CSV का उपयोग करें। रिज़ल्ट को सप्रेशन लूप के ज़रिए इम्पोर्ट करें। सप्रेशन पढ़ना और प्रबंधित करना में कमांड है, और यह भी कि मैन्युअल सप्रेशन ट्रांज़ैक्शनल सहित हर कैटेगरी को क्यों ब्लॉक करता है।
Bird अपने देश-विशिष्ट कैटलॉग के ज़रिए सपोर्टेड stop कीवर्ड संभालता है। सप्रेस्ड पेयर पर send एडमिशन पर E12077 SMSRecipientSuppressed के साथ रिफ़्यूज़ होता है। कैरियर-रिपोर्टेड ऑप्ट-आउट एक अलग recipient_opted_out डिलीवरी रिज़ल्ट है। Plivo error code 200 की हैंडलिंग को उचित एडमिशन और डिलीवरी पाथ से बदलें, और कस्टम रिस्पॉन्स को कीवर्ड नियमों के रूप में दोबारा बनाएँ।
ट्रैफ़िक शुरू होने के बाद यह फिर मायने रखता है। कारण मर्ज नहीं होते, स्टैक होते हैं: जिस पेयर को आपने manual के रूप में इम्पोर्ट किया, अगर वह STOP टेक्स्ट करता है तो उसे keyword_stop कारण से एक दूसरा रिकॉर्ड मिलता है, और मैसेज तब तक रुके रहते हैं जब तक उस पेयर का हर रिकॉर्ड समाप्त न हो जाए। इसलिए एक बार इम्पोर्ट किए गए सब्सक्राइबर को फिर से शुरू करने का मतलब दोनों को हटाना है, और जो resume केवल कीवर्ड रिकॉर्ड साफ़ करता है, वह सफल दिखता है लेकिन कुछ नहीं बदलता।
डिलीवरी स्टेटस का अनुवाद करें
इस तालिका का उपयोग लाइफ़साइकल अवधारणाओं की तुलना के लिए करें, इवेंट का नाम यांत्रिक रूप से बदलने के लिए नहीं। Bird रिपोर्ट किए गए स्टेटस और कारण से failure इवेंट चुनता है। रिफ़्यूज़ की गई API रिक्वेस्ट कोई मैसेज नहीं बनाती; स्वीकृति के बाद रिजेक्शन sms.rejected उत्पन्न कर सकता है, जिसमें कैरियर रिजेक्शन भी शामिल है। डिलीवरी का कोई प्रमाण न मिलने पर स्टेटस unknown रहता है। अपने सामान्यीकृत परिणाम के साथ कच्चा प्रोवाइडर स्टेटस और कोड भी सुरक्षित रखें।
| परिणाम | Plivo message_state | Bird |
|---|---|---|
| API ने मैसेज स्वीकार किया | queued | sms.accepted |
| कैरियर को सौंपा गया | sent | sms.sent |
| कैरियर ने डिलीवरी की पुष्टि की | delivered | sms.delivered |
| कैरियर ने नॉन-डिलीवरी रिपोर्ट की | undelivered | sms.undelivered |
| स्थायी विफलता | failed | sms.failed |
| भेजने से पहले रिफ़्यूज़ | rejected | sms.rejected |
| वैलिडिटी विंडो समाप्त | (कोई नहीं) | sms.expired |
नामों के साथ दो मेकेनिक्स बदलते हैं:
- Endpoint प्रति-मैसेज callback URL की जगह लेते हैं। Plivo प्रत्येक send पर url लेता है, इसलिए गंतव्य कॉल लिखने वाला तय करता है। Bird आपके वर्कस्पेस द्वारा रजिस्टर किए गए endpoint पर डिलीवर करता है, जिनमें से प्रत्येक अपने इच्छित इवेंट टाइप की सब्सक्रिप्शन रखता है, इसलिए नया कंज़्यूमर एक नई सब्सक्रिप्शन है, न कि हर कॉल साइट पर बदलाव।
- हस्ताक्षरित JSON पोस्ट GET callback की जगह लेते हैं, अगर आपने वही चुना था। Plivo का method डिलीवरी रिपोर्ट के लिए GET या POST चुनता है; Bird एक JSON इवेंट POST करता है और कोई GET ऑफ़र नहीं करता। अगर आपने method=GET सेट किया, तो आपका हैंडलर query-string पैरामीटर से परिणाम पढ़ता है, और वह हैंडलर री-रजिस्ट्रेशन नहीं बल्कि रीराइट है। एक गाइड आगे Connectivity Platform पाथ पर भी यही सच है।
- एक सिग्नेचर स्कीम तीन हेडर की जगह लेता है। Plivo कॉलबैक को X-Plivo-Signature-V2, X-Plivo-Signature-Ma-V2 और X-Plivo-Signature-V2-Nonce से साइन करता है। Bird Standard Webhooks के अनुसार साइन किए गए JSON भेजता है, इसलिए वेरिफ़ायर को एडजस्ट नहीं बल्कि रिप्लेस किया जाता है: इसे Webhooks & events में दी गई रेसिपी से बदलें।
Endpoint एक बार रजिस्टर करें, उन इवेंट टाइप का नाम देते हुए जो आपका हैंडलर चाहता है: ऊपर दिए गए sms.* इवेंट सब्सक्राइब करने की सूची हैं, और उनकी जगह लेने वाला कोई वाइल्डकार्ड नहीं है। एक endpoint बनाएँ में कमांड है और पहली कॉल में सही करने वाली एक बात: साइनिंग सीक्रेट को स्टोर करना जो रिस्पॉन्स केवल एक बार दिखाता है।
Plivo के न्यूमेरिक error_code वैल्यू का कोई one-to-one मैप नहीं है। Bird विफलता को एक मानकीकृत error कोड के साथ रिपोर्ट करता है जैसे invalid_destination, content_rejected, provider_unavailable, या recipient_opted_out; पूरी सूची events पेज पर है। अपनी अलर्टिंग इन पर मैप करें।
कटओवर
Destinations, सेंडर, और ट्रैफ़िक रैंप प्रोवाइडर-स्वतंत्र हैं और मुख्य गाइड में कवर हैं। दो Plivo-विशिष्ट आइटम कटओवर प्लान में शामिल होने चाहिए।
आपका 10DLC ब्रांड और कैम्पेन Plivo के ज़रिए The Campaign Registry में रजिस्टर्ड हैं और अपने आप Bird रजिस्ट्रेशन नहीं बनते। पेड वर्क सबमिट करने से पहले लागू माइग्रेशन या रजिस्ट्रेशन प्रक्रिया की पुष्टि करें। यहाँ चेन छोटी है। Plivo पहले एक प्रोफ़ाइल रजिस्टर करता है और फिर उसके विरुद्ध एक ब्रांड, /v1/Account/{auth_id}/10dlc/ के अंतर्गत; Bird में कोई प्रोफ़ाइल ऑब्जेक्ट नहीं है, इसलिए Plivo जो बिज़नेस डिटेल प्रोफ़ाइल पर रखता है वे ब्रांड पर ही दी जाती हैं। 10DLC के लिए रजिस्टर करें से शुरू करें: इसमें हर फ़ील्ड का मतलब, रजिस्ट्री द्वारा मान्य entity टाइप, और requirements कॉल शामिल है जो बताती है कि ब्रांड बनाने से पहले आपको क्या देना है, और यही शुल्क वाला स्टेप है।
Plivo पर आपके मौजूदा नंबरों के लिए एक पोर्ट ज़रूरी है जो सपोर्ट व्यवस्थित करता है, आपकी नहीं बल्कि उनकी समयसीमा पर। इसे जल्दी शुरू करें और यह कोड बदलाव के साथ-साथ चलता रहेगा।
अगले कदम
-
SMS के लिए Bird और Plivo की तुलना: प्रोडक्ट मूल्यांकन और माइग्रेशन विचार
-
SMS भेजना: जिस पेलोड पर आप पोर्ट कर रहे हैं, पूर्ण विवरण
-
ऑप्ट-आउट और कीवर्ड: देश के अनुसार कीवर्ड कवरेज और सप्रेशन प्रबंधन
-
SMS events: इवेंट शब्दावली जिस पर आपका callback हैंडलर जाता है
-
Webhooks & events: endpoint सेटअप और Standard Webhooks सत्यापन
संबंधित संसाधन
इस विषय के लिए डॉक्यूमेंटेशन, गाइड और उदाहरणों के साथ आगे बढ़ें। संसाधन अंग्रेज़ी में हैं।