Bird

Migrate from Infobip RCS to Bird

Start by identifying whether your integration uses Infobip's RCS API, Messages API or a campaign/service workflow. The mapping below targets the native RCS API. Keep your appointment, order and customer IDs stable while replacing provider transport IDs and payloads.

Map the integration

Infobip's RCS send tutorial uses /rcs/2/messages, Authorization: App, a messages array, and per-message sender, destinations and content. Rebuild the receiving request for Bird's Channels API:
Infobip input or recordBird implementation
API key and senderUse a Bird access key and the installed agent's workspace/channel IDs. Send to https://api.bird.com/workspaces/{workspaceId}/channels/{channelId}/messages.
destinations[].toPut your test E.164 number in receiver.contacts[] with identifierKey: "phonenumber" and identifierValue.
content.type: "TEXT"Use body.type: "text" and body.text.text.
content.type: "CARD"Use body.type: "carousel" with one item in body.carousel.items. Rebuild media and actions for that item.
suggestions with OPEN_URLUse an item action of type link with link.text and link.url.
Suggested reply postbackDataPreserve its business meaning as a Bird postback.payload, with the button label in postback.text.
bulkId and per-recipient messageIdRetain old IDs for support. Save the new Bird id and your own reference for each submitted customer task.
Recreate the agent's business identity and launch markets with the Bird setup procedure. Confirm the sender transition and new agent's launch state before routing existing customers; old provider IDs are not interchangeable with Bird channel IDs.
Infobip's RCS API guide covers capability checks and SMS/MMS failover. If you use them, inventory the existing ordering, content and timing. Configure a Bird Navigator for RCS-to-SMS delivery, including launch-country scope and platform suppressions. A direct RCS channel POST does not select a navigator automatically.

Build and test the receiving path

Run the Node.js, Python or cURL quickstart against your own tester. Keep one sample appointment and verify these cases:
TestEvidence to retain
Single card and URL actionBird message ID, native rendering and the correct application destination.
Two-card choiceDistinct payloads reach the intended options; stale availability produces a fresh choice.
Suggested replyrcs-google.inbound reaches the handler; the postback maps to the same customer task.
Repeated replyReplayed input and a second click do not create duplicate application actions.
RCS reach failure with SMS fallbackNavigator attempt list identifies the failed RCS leg and the eligible SMS result.
Opt-out and uncertain resultOpt-out stops the relevant chain; an uncertain send does not create an application retry.
Use the rich-message payloads and handler. Replace provider webhook parsing as well as the outgoing payload. Bird delivery states and read/clicked interactions are separate records; use their documented meanings instead of copying an Infobip status code into your success field.

Switch traffic and reconcile

Route a bounded customer cohort to Bird with one active sending owner per business task. Store provider name, sender/channel, transport message ID and business reference together. Keep each provider's callback handler available while its earlier messages remain in flight.
Compare delivery outcomes at the same scope: a Bird navigator success may include an unsuccessful RCS attempt followed by SMS. Compare native RCS reach separately from completed appointment actions and overall chain delivery. Keep migrated opt-outs current as replies arrive through either provider during the transition.
If a cohort fails, stop assigning new work to that route and inspect the recorded attempts. Routing new work back does not cancel accepted messages. Reconcile uncertain outcomes before resubmitting the same reminder.

References and next steps

Sumber daya terkait

Lanjutkan dengan dokumentasi, panduan, dan contoh untuk topik ini. Sumber daya tersedia dalam bahasa Inggris.

Dapatkan ringkasan implementasi