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

यह पेज Sinch के SMS API, groups और delivery reports को Bird पर मैप करता है। [मुख्य माइग्रेशन गाइड](/docs/guides/sms/migrate) को क्रम से फ़ॉलो करें और स्टेप 3, 4 और 5 के लिए इन मैपिंग्स का उपयोग करें।

दो संरचनात्मक अंतर इस पोर्ट को आकार देते हैं, और दोनों की लागत फ़ील्ड रीनेम से ज़्यादा है। Sinch URL path में एक service plan पर send को key करता है और एक **batch** भेजता है, इसलिए एक व्यक्ति को एक मैसेज भेजना भी array ही रहता है; Bird का [`POST /v1/sms/messages`](/docs/api/reference/create-sms-message) आपके regional host पर bearer key के साथ एक प्राप्तकर्ता लेता है और कोई plan segment नहीं होता। और US registration जिसे आप छोड़ नहीं सकते, send से अलग host पर है, अलग credential family के पीछे है, इसलिए जो कोडबेस दोनों के लिए Sinch तक पहुँचता है वह दो जगहों तक पहुँच रहा है।

## यह अपने एजेंट को दें

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

```text
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.
```

## Send कॉल को मैप करें

| क्या करता है            | Sinch                                           | Bird                                          |
| ----------------------- | ----------------------------------------------- | --------------------------------------------- |
| प्राप्तकर्ता            | `to` (array, या group ID)                       | `to` (प्रति request एक)                       |
| प्रेषक                  | `from`                                          | `from`                                        |
| बॉडी                    | `body`                                          | `text`                                        |
| अकाउंट रूटिंग           | service plan, URL path में                      | bearer key; कोई path segment नहीं             |
| इंटेंट                  | (कोई नहीं)                                      | `category`, free text पर आवश्यक               |
| डिलीवरी रिपोर्टिंग      | `delivery_report` + `callback_url`, प्रति batch | एक वर्कस्पेस webhook; प्रति-send कंट्रोल नहीं |
| कोरिलेशन                | `client_reference`                              | `metadata`, हर event पर echo होता है          |
| फ़िल्टर करने योग्य लेबल | (कोई नहीं)                                      | `tags`: `{name, value}` पेयर                  |
| सुरक्षित फिर से प्रयास  | (कोई दस्तावेज़ नहीं)                            | `Idempotency-Key` हेडर                        |
| Flash                   | `flash_message`                                 | कोई समकक्ष नहीं                               |

पोर्टिंग नोट्स:

- **सोच-समझकर सिंगल send, batch या broadcast चुनें।** `to` Sinch पर एक array है और यहाँ एक सिंगल नंबर है, इसलिए सिंगल send या 100 तक स्वतंत्र मैसेज के लिए batch endpoint का उपयोग करें। ऑडियंस कैम्पेन [broadcast वर्कफ़्लो](/products/sms/marketing/campaigns) में आता है। जिस batch ने एक group नाम दिया था, उसकी membership पहले resolve करनी होगी; opt-out सेक्शन देखें, क्योंकि वह वही समस्या है।
- **`body` अब `text` बन जाता है।** यह वह एक रीनेम है जो हर call site को बदलता है।
- **`client_reference` एक idempotency key नहीं है।** Sinch इसे batch की delivery report में जोड़े गए एक identifier के रूप में परिभाषित करता है, इसलिए यह correlate करता है लेकिन deduplicate नहीं करता। अगर आप इस पर निर्भर थे कि यह फिर से प्रयास करना सुरक्षित बनाएगा, तो आप कवर नहीं थे; यहाँ यह काम `Idempotency-Key` करता है।
- **`category` के लिए कोई समकक्ष नहीं है।** प्रति मैसेज टाइप तय करें कि यह `transactional`, `marketing`, `authentication` है या `service`।

## Opt-outs को कैरी ओवर करें

**Sinch रिकॉर्ड करता है कि कौन शामिल है, और Bird को जानना होगा कि कौन बाहर है।** यह उलटाव ही असली काम है।

Sinch प्राप्तकर्ताओं को groups के रूप में मैनेज करता है, और एक group keyword triggers से auto-update हो सकता है, इसलिए जो subscriber `STOP` टेक्स्ट करता है उसे group से हटा दिया जाता है और जो subscriber `SUBSCRIBE` टेक्स्ट करता है उसे जोड़ दिया जाता है। Opt-out इसलिए किसी लिस्ट पर उपस्थिति के बजाय _अनुपस्थिति_ के रूप में एन्कोड होता है, और अनुपस्थिति एक्सपोर्ट नहीं की जा सकती: group से गायब नंबर ने opt out किया हो सकता है, कभी जुड़ा ही न हो, या छह महीने पहले किसी import से हटाया गया हो।

इसलिए एक्सपोर्ट करने के बजाय reconstruct करें। आपका अपना inbound-message लॉग विश्वसनीय स्रोत है, क्योंकि कुछ opt-outs inbound मैसेज के रूप में शुरू हुए, जबकि अन्य support, forms या किसी अन्य preference चैनल से आए, और वे मैसेज group membership अभी जो भी कहती हो, मौजूद हैं। जहाँ आपने group के साथ अपना खुद का unsubscribe flag रखा था, वह flag membership से बेहतर प्रमाण है। reconstructed लिस्ट को [suppression loop](/docs/guides/sms/migrate#4-carry-over-your-opt-out-list) में ले जाएँ, और import करने से पहले लिस्ट उस व्यक्ति को दिखाएँ जो अकाउंट का मालिक है: यहाँ एक गलत entry उन मैसेज को चुपचाप रोक देती है जो आप भेजना चाहते थे।

Bird suppression एक sender-और-subscriber जोड़ी है, इसलिए जिस subscriber को आप तीन senders पर रोकते हैं वह तीन रिकॉर्ड है। [Suppressions पढ़ना और मैनेज करना](/docs/guides/sms/opt-outs-and-keywords#reading-and-managing-suppressions) में कमांड है, और वह कारण जिसकी वजह से manual suppression transactional सहित हर category को ब्लॉक करता है।

एक बार जब आप यहाँ हैं, Bird प्रति देश अपने catalog से stop keywords का जवाब खुद देता है, इसलिए group auto-update व्यवहार को दोबारा बनाने की ज़रूरत नहीं है: जो subscriber `STOP` टेक्स्ट करता है, वह आपके एप्लिकेशन के बिना कुछ किए suppression बना देता है। कारण merge होने के बजाय stack होते हैं, इसलिए जिस जोड़ी को आपने `manual` के रूप में import किया और जिसने बाद में `STOP` टेक्स्ट किया, उसके पास दो रिकॉर्ड होते हैं, और दोनों समाप्त होने तक मैसेज रुके रहते हैं।

## Delivery statuses का अनुवाद करें

इस टेबल का उपयोग lifecycle अवधारणाओं की तुलना के लिए करें, events का यांत्रिक रूप से नाम बदलने के लिए नहीं। Bird रिपोर्ट किए गए status और reason से failure event चुनता है। अस्वीकृत API request कोई मैसेज नहीं बनाता; acceptance के बाद rejection `sms.rejected` उत्पन्न कर सकता है, जिसमें carrier rejection भी शामिल है। गायब delivery प्रमाण unknown रहता है। अपने normalized outcome के साथ raw provider status और code भी रखें।

Sinch के [delivery-report reference](https://developers.sinch.com/docs/sms/api-reference/sms/delivery-reports/getdeliveryreportbybatchid) में queued, dispatched, delivered और कई अलग-अलग अंतिम failure states शामिल हैं। अपनी रिपोर्टिंग का अनुवाद करते समय recipient-level code और status को सुरक्षित रखें।

| Sinch अवधारणा                       | Bird इंटीग्रेशन निर्णय                                                                                                                        |
| ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| `Queued` / `Dispatched`             | `sms.accepted` और `sms.sent` से acceptance और carrier submission को अलग-अलग ट्रैक करें।                                                       |
| `Delivered`                         | `sms.delivered` के ज़रिए नेटवर्क outcome रिकॉर्ड करें; यह पढ़ा जाना साबित नहीं करता।                                                          |
| `Failed` / `Rejected` / `Deleted`   | रिपोर्ट किए गए reason की जाँच करें। Bird failure events सिर्फ़ नाम बदलने से नहीं चुने जाते।                                                   |
| `Aborted` / `Expired` / `Cancelled` | cause और stage को सुरक्षित रखें। Bird के individual-send API में इन controls को फिर से बनाने के लिए कोई scheduling या validity timer नहीं है। |
| `Unknown`                           | outcome अनिश्चित रखें; किसी गायब interpretable receipt को delivery न गिनें।                                                                   |

Bird का `sms.expired` एक carrier expiry report का अनुसरण करता है। हर timeout को उसमें मैप करने के बजाय अपने मौजूदा expiry और cancellation व्यवहार की उस event से अलग समीक्षा करें।

यह भी ध्यान दें कि intermediate statuses तभी रिपोर्ट होते हैं जब batch ने `per_recipient` रिपोर्टिंग माँगी हो, जो नीचे बदलने वाली चीज़ों का हिस्सा है।

**आप delivery reporting का प्रति-send कंट्रोल खो देते हैं, और यह साफ़ कहना ज़रूरी है।** Sinch batch अपनी report granularity खुद चुनता है और उस send के लिए service plan की callback URL को override कर सकता है। Bird में दोनों में से कुछ नहीं है: reporting एक वर्कस्पेस subscription है, हर subscribed event डिलीवर होता है, और कोई per-message override नहीं है। अगर आप `delivery_report` का उपयोग chatty campaigns को शांत रखने के लिए कर रहे थे, तो वह फ़िल्टरिंग आपके handler में चली जाती है। अगर आप एक campaign की reports को अलग endpoint पर रूट कर रहे थे, तो वह एक endpoint प्लस एक branch बन जाता है, या दूसरा subscription।

Endpoint को एक बार register करें और वे event types नाम दें जो आपका handler चाहता है: ऊपर दिए गए `sms.*` events वही लिस्ट है जिसे subscribe करना है, और कोई wildcard नहीं है जो उनकी जगह ले। Bird [Standard Webhooks](https://www.standardwebhooks.com) के अनुसार signed JSON भेजता है; [एक endpoint बनाएँ](/docs/guides/webhooks#create-an-endpoint) में कमांड है और पहली कॉल पर सही करने वाली एक बात यह है कि response में दिखने वाले signing secret को स्टोर करें जो सिर्फ़ एक बार दिखता है।

Bird एक failure को standardized `error` code के साथ रिपोर्ट करता है जैसे `invalid_destination`, `content_rejected`, `provider_unavailable`, या `recipient_opted_out`; पूरी लिस्ट [events पेज](/docs/guides/sms/events#failure-events) पर है।

## कट ओवर

[Destinations](/docs/guides/sms/migrate#1-enable-your-destination-countries), [senders](/docs/guides/sms/migrate#2-set-up-a-sender), और [ट्रैफ़िक रैम्प](/docs/guides/sms/migrate#6-test-against-simulated-destinations) provider-independent हैं और मुख्य गाइड में कवर हैं। दो Sinch-विशिष्ट आइटम cutover प्लान में शामिल होने चाहिए।

आपका 10DLC brand और campaign Sinch के ज़रिए The Campaign Registry में registered हैं और स्वचालित रूप से Bird registrations नहीं बनते। paid work सबमिट करने से पहले लागू migration या registration प्रक्रिया की पुष्टि करें। **यहीं पर integration सरल होता है।** Sinch पर registration API send से अलग host पर है और service plan token के बजाय project credentials लेता है, और Sinch का अपना documentation कहता है कि HTTP Basic वहाँ केवल test उद्देश्यों के लिए है और भारी रूप से दर सीमित है, इसलिए एक production integration इसके लिए OAuth token flow बनाता है। Bird पर `/v1/sms/10dlc/*` एक base URL और एक key के तहत `/v1/sms/messages` के बगल में बैठता है, इसलिए वह token lifecycle पोर्ट होने के बजाय retire होता है। [10DLC के लिए रजिस्टर करें](/docs/guides/sms/10dlc) से शुरू करें, जो कवर करता है कि हर फ़ील्ड का क्या मतलब है और वह requirements कॉल जो बताती है कि brand बनाने से पहले क्या देना है, जो कि चार्ज होने वाला कदम है।

Sinch पर आपके जो नंबर हैं उनके लिए एक पोर्ट चाहिए जो support अरेंज करता है, आपके नहीं बल्कि उसके शेड्यूल पर।

## अगले कदम

- [SMS के लिए Bird और Sinch की तुलना करें](/products/sms/compare/bird-vs-sinch): product evaluation और migration विचार

- [SMS भेजना](/docs/guides/sms/sending-sms): वह पेलोड जिस पर आप पोर्ट कर रहे हैं, पूरी तरह
- [Opt-outs और keywords](/docs/guides/sms/opt-outs-and-keywords): प्रति देश keyword कवरेज और suppression प्रबंधन
- [SMS events](/docs/guides/sms/events): वह event vocabulary जिस पर आपका report handler जाता है
- [Webhooks & events](/docs/guides/webhooks): endpoint सेटअप और Standard Webhooks सत्यापन

## Related resources

- [Choose a sender for your markets](/explained/sms/which-sms-sender-type-should-i-use) (answer)
- [Check your message segments](/tools/sms-segment-calculator) (tool)
- [Compare SMS providers](/products/sms/compare) (product)