Migrate Apple Messages from Linq to Bird
Identify the Linq channel first. Its Apple Messages for Business API uses messages.api.linqapp.com/v1; its separate V3 API handles consumer iMessage, RCS and SMS. This guide maps the business channel. Moving from consumer iMessage changes the customer journey as well as the API.
1. Prepare the receiving business
Keep the existing integration available while you complete Bird business registration and agree the provider change for the Apple business. Test the new entry point and conversation before switching traffic. Do not assume that a provider change transfers open chats or provider-generated IDs.
2. Map requests and responses
Keep an inventory of the existing business-channel integration and map it to the receiving service workflow:
| Linq Apple Messages record | Receiving setup and test |
|---|---|
| Brand credentials and chat identity | Connect the approved Apple business and open a new Bird test conversation. Retain the old chat reference for history. |
| Text and native message parts | Prepare the same customer-visible text or native choice using the receiving template. |
| Request and grouped message outcomes | Keep the previous provider’s request and message references separately from new Bird message records. |
| Send retry identity | Resolve uncertain sends with their original provider before routing a new reply through another provider. |
| Open chat and send-turn ownership | Rebuild the assistant and human handoff before moving the service. |
Complete the registration and conversation test. In the new Bird conversation, send “How can we help with your booking?” through Reply to the customer. Inspect the recorded status and the reply on the device.
Next, prepare the repair-service list. Return a selection on the device and confirm its meaning in the receiving service system. This verifies the customer journey without assuming the two providers share request bodies, credentials or identifiers.
3. Rebuild message and business state separately
Linq documents queued and eventual sent/failed processing; its business-channel sent is not a device delivery or read receipt. Bird also distinguishes Apple gateway acceptance from device observation. Do not import consumer iMessage delivery semantics into the business-channel handler.
Map each native reply to the application request that produced it. A selected appointment must still pass the scheduling system’s availability check. Restore customer consent and human handoff using the receiving workflow rather than treating an old provider’s state as authorization for a new send.
4. Test the change and move traffic
Test text, a native choice, a repeated callback, a closed conversation and an agent handoff. Check a timeout after submission without switching providers automatically; a second provider does not know whether the first one sent the message. Route each new logical reply to one provider and retain both event handlers while old work settles.
For a consumer iMessage integration, rebuild entry points around the registered business. A phone number or Linq V3 chat is not a Bird Apple conversation. Evaluate SMS or RCS separately when that is the customer’s required channel.
Channel policy and sources
Apple’s consumer iMessage policy excludes commercial activities and warns of service limitations for misuse. That statement does not establish that Linq as a company is illegal, and it must not be applied indiscriminately to Linq’s separate business-channel product. Review Linq’s channel distinction and send contract for the specific integration you use.
Next steps
- Compare Bird and Linq
- Native rich messages
- Service and agent handoff
- SMS migration guides
- RCS migration guides
Related resources
Continue with the documentation, guides and examples for this topic. Resources are in English.
Understand the conceptWhat is Apple Messages for Business?Explore the capabilityApple Messages for BusinessImplementation guideIntegrate an Apple Messages customer journey
Get an implementation brief