# Migracja SMS z Sinch

Ta strona mapuje SMS API, grupy i raporty doręczeń z Sinch na Bird. Wykonuj [główny przewodnik migracji](/docs/guides/sms/migrate) po kolei, a tych mapowań użyj w krokach 3, 4 i 5.

Dwie różnice strukturalne kształtują tę migrację i obie kosztują więcej niż same zmiany nazw pól. Sinch identyfikuje wysyłkę po planie usługowym w ścieżce URL i wysyła **batch**, więc jedna wiadomość do jednej osoby to wciąż tablica; [`POST /v1/sms/messages`](/docs/api/reference/create-sms-message) w Bird przyjmuje jednego odbiorcę na Twoim regionalnym hoście z kluczem bearer i bez segmentu planu. Rejestracja w USA, której nie możesz pominąć, jest na innym hoście niż wysyłka, za inną rodziną poświadczeń, więc kod, który kontaktuje się z Sinch w obu celach, trafia w dwa miejsca.

## Przekaż to swojemu agentowi

Użyj tego opisu w swoim agencie kodującym. Zaczyna od rozpoznania i tworzy plan migracji do przeglądu, zanim cokolwiek zmieni się na produkcji.

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

## Zmapuj wywołanie wysyłki

| Co robi               | Sinch                                         | Bird                                                 |
| --------------------- | --------------------------------------------- | ---------------------------------------------------- |
| Odbiorca              | `to` (tablica lub ID grupy)                   | `to` (jeden na żądanie)                              |
| Nadawca               | `from`                                        | `from`                                               |
| Treść                 | `body`                                        | `text`                                               |
| Routing konta         | plan usługowy, w ścieżce URL                  | klucz bearer; bez segmentu ścieżki                   |
| Intencja              | (brak)                                        | `category`, wymagane dla dowolnego tekstu            |
| Raportowanie doręczeń | `delivery_report` + `callback_url`, per batch | webhook obszaru roboczego; brak kontroli per wysyłkę |
| Korelacja             | `client_reference`                            | `metadata`, zwracane w każdym zdarzeniu              |
| Filtrowalne etykiety  | (brak)                                        | pary `tags`: `{name, value}`                         |
| Bezpieczne ponawianie | (brak w dokumentacji)                         | nagłówek `Idempotency-Key`                           |
| Flash                 | `flash_message`                               | brak odpowiednika                                    |

Uwagi do migracji:

- **Świadomie wybierz pojedynczą wysyłkę, batch lub broadcast.** `to` w Sinch jest tablicą, a tutaj pojedynczym numerem, więc używaj pojedynczych wysyłek albo endpointu batch dla maksymalnie 100 niezależnych wiadomości. Kampania do grupy odbiorców należy do [workflow broadcast](/products/sms/marketing/campaigns). Batch, który wskazywał grupę, wymaga najpierw rozwiązania członkostwa; zobacz sekcję o rezygnacjach, bo to ten sam problem.
- **`body` staje się `text`.** To jedyna zmiana nazwy, która dotyczy każdego miejsca wywołania.
- **`client_reference` nie jest kluczem idempotentności.** Sinch definiuje go jako identyfikator dodawany do raportu doręczenia batcha, więc koreluje, ale nie deduplikuje. Jeśli polegałeś na nim, żeby ponowienie było bezpieczne, nie byłeś chroniony; tutaj robi to `Idempotency-Key`.
- **Nic nie odpowiada `category`.** Zdecyduj per typ wiadomości, czy to `transactional`, `marketing`, `authentication` czy `service`.

## Przenieś rezygnacje

**Sinch rejestruje, kto jest zapisany, a Bird potrzebuje wiedzieć, kto zrezygnował.** Ta inwersja to właściwa praca.

Sinch zarządza odbiorcami jako grupami, a grupa może się automatycznie aktualizować na podstawie słów kluczowych: subskrybent, który wyśle `STOP`, jest usuwany z grupy, a subskrybent, który wyśle `SUBSCRIBE`, jest dodawany. Rezygnacja jest więc zakodowana jako _nieobecność_ na liście, a nie obecność na niej, a nieobecności nie da się wyeksportować: numer, którego brak w grupie, mógł zrezygnować, mógł nigdy nie dołączyć albo mógł zostać usunięty importem sześć miesięcy temu.

Odtwórz dane zamiast je eksportować. Twój własny log wiadomości przychodzących jest wiarygodnym źródłem, bo część rezygnacji rozpoczęła się jako wiadomości przychodzące, a inne przyszły przez wsparcie, formularze lub inny kanał preferencji, i te wiadomości istnieją niezależnie od tego, co teraz mówi członkostwo w grupie. Jeśli oprócz grupy trzymałeś własną flagę rezygnacji, ta flaga jest lepszym dowodem niż członkostwo. Przekaż odtworzoną listę do [pętli wyciszeń](/docs/guides/sms/migrate#4-carry-over-your-opt-out-list) i pokaż ją osobie odpowiedzialnej za konto przed importem: błędny wpis tutaj po cichu zatrzymuje wiadomości, które zamierzałeś wysłać.

Wyciszenie w Bird to jedna para nadawca–subskrybent, więc subskrybent wyciszony u trzech nadawców to trzy rekordy. [Odczyt i zarządzanie wyciszeniami](/docs/guides/sms/opt-outs-and-keywords#reading-and-managing-suppressions) zawiera polecenie oraz wyjaśnia, dlaczego ręczne wyciszenie blokuje każdą kategorię, łącznie z transakcyjną.

Od tego momentu Bird samodzielnie odpowiada na słowa kluczowe stop z własnego katalogu per kraj, więc automatyczna aktualizacja grupy nie ma odpowiednika do odtworzenia: subskrybent, który wyśle `STOP`, tworzy wyciszenie bez udziału Twojej aplikacji. Powody się kumulują, a nie zastępują, więc para zaimportowana jako `manual`, która później wyśle `STOP`, ma dwa rekordy i wiadomości pozostają wstrzymane, dopóki oba się nie zakończą.

## Przetłumacz statusy doręczeń

Użyj tej tabeli do porównania koncepcji cyklu życia, a nie do mechanicznej zamiany nazw zdarzeń. Bird wybiera zdarzenie błędu na podstawie zgłoszonego statusu i powodu. Odrzucone żądanie API nie tworzy wiadomości; odrzucenie po akceptacji może wygenerować `sms.rejected`, w tym odrzucenie przez operatora. Brak dowodu doręczenia pozostaje nieznany. Zachowaj surowy status i kod dostawcy obok znormalizowanego wyniku.

[Referencja raportów doręczeń](https://developers.sinch.com/docs/sms/api-reference/sms/delivery-reports/getdeliveryreportbybatchid) Sinch obejmuje statusy queued, dispatched, delivered i kilka odrębnych końcowych stanów błędu. Zachowaj kod i status na poziomie odbiorcy podczas translacji raportowania.

| Koncepcja Sinch                     | Decyzja integracyjna Bird                                                                                                          |
| ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| `Queued` / `Dispatched`             | Śledź akceptację i przekazanie do operatora osobno za pomocą `sms.accepted` i `sms.sent`.                                          |
| `Delivered`                         | Rejestruj wynik sieciowy przez `sms.delivered`; nie dowodzi odczytania.                                                            |
| `Failed` / `Rejected` / `Deleted`   | Sprawdź zgłoszony powód. Zdarzenia błędu Bird nie są wybierane przez prostą zamianę nazw.                                          |
| `Aborted` / `Expired` / `Cancelled` | Zachowaj przyczynę i etap. Pojedyncza wysyłka API w Bird nie ma timera harmonogramu ani ważności, który odtworzyłby te mechanizmy. |
| `Unknown`                           | Pozostaw wynik jako niepewny; nie traktuj braku interpretowalnego potwierdzenia jako doręczenia.                                   |

`sms.expired` w Bird następuje po raporcie wygaśnięcia od operatora. Przeanalizuj istniejące zachowanie wygaśnięcia i anulowania osobno od tego zdarzenia, zamiast mapować każdy timeout na nie.

Statusy pośrednie są raportowane tylko wtedy, gdy batch zażądał raportowania `per_recipient`, co jest częścią tego, co zmienia się poniżej.

**Tracisz kontrolę raportowania doręczeń per wysyłkę i warto powiedzieć to wprost.** Batch Sinch wybiera własną granularność raportu i może nadpisać callback URL planu usługowego dla tej jednej wysyłki. Bird nie ma żadnego z tych mechanizmów: raportowanie to subskrypcja obszaru roboczego, każde subskrybowane zdarzenie jest dostarczane i nie ma nadpisania per wiadomość. Jeśli używałeś `delivery_report`, żeby wyciszyć głośne kampanie, to filtrowanie przenosi się do Twojego handlera. Jeśli kierowałeś raporty jednej kampanii na inny endpoint, teraz to jeden endpoint plus rozgałęzienie albo druga subskrypcja.

Zarejestruj endpoint raz, podając typy zdarzeń, które chce obsługiwać Twój handler: zdarzenia `sms.*` wymienione powyżej to lista do subskrypcji i nie ma wildcard, który je zastępuje. Bird wysyła JSON podpisane zgodnie ze [Standard Webhooks](https://www.standardwebhooks.com); [Utwórz endpoint](/docs/guides/webhooks#create-an-endpoint) zawiera polecenie i jedną rzecz do poprawnego wykonania przy pierwszym wywołaniu, czyli zapisanie sekretu podpisu, który odpowiedź pokazuje dokładnie raz.

Bird raportuje błąd ze standardowym kodem `error`, takim jak `invalid_destination`, `content_rejected`, `provider_unavailable` lub `recipient_opted_out`; pełna lista znajduje się na [stronie zdarzeń](/docs/guides/sms/events#failure-events).

## Przełączenie

[Destynacje](/docs/guides/sms/migrate#1-enable-your-destination-countries), [nadawcy](/docs/guides/sms/migrate#2-set-up-a-sender) i [rampa ruchu](/docs/guides/sms/migrate#6-test-against-simulated-destinations) są niezależne od dostawcy i opisane w głównym przewodniku. Dwa elementy specyficzne dla Sinch należy umieścić w planie przełączenia.

Twoja marka i kampania 10DLC są zarejestrowane w The Campaign Registry przez Sinch i nie stają się automatycznie rejestracjami Bird. Potwierdź właściwą procedurę migracji lub rejestracji, zanim zlecisz płatne prace. **Tu właśnie integracja się upraszcza.** W Sinch API rejestracji jest na osobnym hoście od wysyłki i używa poświadczeń projektu zamiast tokenu planu usługowego, a własna dokumentacja Sinch mówi, że HTTP Basic jest przeznaczony tylko do celów testowych i ma silne ograniczanie liczby żądań, więc integracja produkcyjna buduje przepływ tokenów OAuth. W Bird `/v1/sms/10dlc/*` znajduje się obok `/v1/sms/messages` pod jednym bazowym URL i jednym kluczem, więc ten cykl życia tokenów jest wycofywany, a nie przenoszony. Zacznij od [Rejestracja 10DLC](/docs/guides/sms/10dlc), która opisuje znaczenie każdego pola i wywołanie requirements, które mówi, co podać, zanim utworzysz markę, bo to jest krok płatny.

Numery, które posiadasz w Sinch, wymagają przeniesienia, które organizuje wsparcie, według własnego harmonogramu, nie Twojego.

## Następne kroki

- [Porównanie Bird i Sinch dla SMS](/products/sms/compare/bird-vs-sinch): ocena produktu i kwestie migracyjne

- [Wysyłanie SMS](/docs/guides/sms/sending-sms): pełny payload, na który migrujesz
- [Rezygnacje i słowa kluczowe](/docs/guides/sms/opt-outs-and-keywords): pokrycie słów kluczowych per kraj i zarządzanie wyciszeniami
- [Zdarzenia SMS](/docs/guides/sms/events): słownik zdarzeń, na który przechodzi Twój handler raportów
- [Webhooks i zdarzenia](/docs/guides/webhooks): konfiguracja endpointu i weryfikacja 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)