Migrate from LoopMessage
Move your LoopMessage integration to Apple Messages for Business on Blooio: the endpoint and webhook mapping, a copy-for-AI prompt that switches your code over, and the three steps from sandbox to live.
This guide moves an existing LoopMessage integration to Blooio and onto Apple Messages for Business, Apple's official channel for businesses. Your business logic stays the same. What changes is the transport: the endpoints, the auth header, and the webhook fields, all mapped below.
The three steps
- Get a free sandbox and build. Connect a free Apple Messages for Business sandbox, point your code at the Blooio API, and build your bot with every feature unlocked: quick replies, list pickers, forms, Apple Pay, and live agent handoff.
- Submit to Apple's Experience Review. Apple tests the whole conversation before you go live. Blooio records the walkthrough and submits it for you, and the AI bot on the Growth plan already checks every box Apple looks for.
- Go live. Once Apple approves, turn on the Message button in Maps, Search, your site, and your app. Customers who can't be reached on Apple Messages for Business fall back to RCS Business Messaging, then SMS.
Endpoint and field mapping
| Task | LoopMessage | Blooio v4 |
|---|---|---|
| Authenticate | Authorization: $LOOP_API_KEY (no Bearer prefix) |
Authorization: Bearer $BLOOIO_API_KEY |
| Start a conversation | POST /api/v1/message/send/ with contact, text, sender |
POST /v4/messages with to, text, and optional from |
| Reply in a thread | POST /api/v1/message/send/ with the same contact |
POST /v4/chats/{chatId}/messages with text |
| Send media | attachments (array of URLs) |
attachments |
| Choose the channel | channel override (imessage, sms, rcs) |
Channel priority: Apple Messages for Business, then RCS Business Messaging, then SMS |
| Receive messages | message_inbound webhook with contact, text, message_id |
message.received webhook with data.sender, data.text, data.message_id |
| Track delivery | message_sent and message_failed webhooks |
message.delivered and message.failed webhooks |
- LoopMessage's
senderis a sender name tied to your account. On Apple Messages for Business the sender is your verified brand, addressed by its alias.
LoopMessage's own reference: https://loopmessage.com/apidocs/send-message/.
Before and after
LoopMessage:
curl -X POST https://a.loopmessage.com/api/v1/message/send/ \
-H "Authorization: $LOOP_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"contact": "+15551234567",
"sender": "$LOOP_SENDER_ID",
"text": "Thanks for reaching out. How can we help?"
}'Blooio:
curl -X POST https://api.blooio.com/v4/chats/$CHAT_ID/messages \
-H "Authorization: Bearer $BLOOIO_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: $(uuidgen)" \
-d '{
"text": "Thanks for reaching out. How can we help?"
}'Try itReceive messages
Every inbound message arrives as a message.received webhook. On Apple Messages for Business the sender is an opaque id Apple mints for that customer and your brand, not a phone number. Reply to data.chat_id and the thread stays intact.
{
"id": "evt_018f7b2a-1c3d-7e4f-9a2b-0c1d2e3f4a5b",
"type": "message.received",
"data": {
"message_id": "msg_018f7b2a-8e5b-7f00-a1b2-0f1a2b3c4d5e",
"chat_id": "chat_018f7b2a-77aa-7c22-9d3e-4f5a6b7c8d9e",
"channel_type": "amb",
"direction": "inbound",
"sender": "opaque-amb-customer-id",
"text": "Where's my order?",
"attachments": []
}
}Teach your bot the Apple Messages for Business payloads
Apple reviews the whole conversation before you go live, so the bot has to behave the way Apple expects, not just deliver text. The first reply should disclose that it is automated and triage with a Quick Reply of your top four reasons plus "Something else":
curl -X POST https://api.blooio.com/v4/chats/$CHAT_ID/messages \
-H "Authorization: Bearer $BLOOIO_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: $(uuidgen)" \
-d '{
"interactive": {
"kind": "quick_reply",
"summary_text": "Hi, I'm Blue, Acme's automated assistant. What can I help with?",
"items": [
{ "id": "order", "title": "Track an order" },
{ "id": "return", "title": "Start a return" },
{ "id": "billing", "title": "Billing" },
{ "id": "store", "title": "Store hours" },
{ "id": "other", "title": "Something else" }
]
}
}'Try it| When the bot needs to | Send |
|---|---|
| Offer 2 to 5 choices | interactive with kind: "quick_reply" |
| Offer a longer list | interactive with kind: "list_picker" |
| Book an appointment | interactive with kind: "time_picker" |
| Collect several answers | interactive with kind: "form" |
| Take payment | interactive with kind: "apple_pay" |
| Sign the customer in | interactive with kind: "authenticate" |
| Share a URL | rich_link, never a bare link |
| Look busy while working | POST /v4/chats/{chatId}/typing, about a second before each reply |
Every rule Apple checks, from the 5-second welcome to live agent handoff and keywords, is in Pass the Experience Review. The payload shapes are in Interactive messages.
Smart fallbacks to RCS Business Messaging and SMS
Not every customer is on an Apple device, and Apple Messages for Business conversations always start with the customer. Put your channels in a priority: Apple Messages for Business first, RCS Business Messaging second, SMS third. Send without from and Blooio picks the right channel for each customer, so the same code reaches iPhone, Android, and everything else.
Outbound
Apple Messages for Business is customer-initiated. The only business-first message is an Apple-approved business invitation to a customer who opted in. Move cold outbound campaigns to RCS Business Messaging or SMS through the same API.
Skip all of this
Blooio can run the whole migration.
We build the bot to Apple's rules, wire up your fallbacks, record and submit the Experience Review, and watch for drift after launch.