Channel guide
Does Twilio support iMessage?
No. Twilio does not offer an API for sending ordinary blue-bubble iMessages to a phone number. Its only iMessage-adjacent product is Apple Messages for Business, a separate branded channel in private beta since 7 May 2026.
Does Twilio support iMessage? No, only Apple Messages for Business
No. Twilio does not offer an API for sending ordinary blue-bubble iMessages to a phone number.
Its only iMessage-adjacent product is Apple Messages for Business, a separate branded channel that entered private beta on 7 May 2026 (still in private beta on 16 October 2026) and requires Apple business registration.
To send and receive iMessage from an ordinary phone number through an API, use a hosted phone-number provider such as Comms by Osis ($200/month for a dedicated line, $0 setup), and check recipient capability before sending.
If you specifically need Apple’s verified business identity and entry points, Apple Messages for Business is the right channel.
Check the channel before comparing providers
Ask which sender identity, customer entry points, account approval and supported messaging features the product uses. Ordinary iMessage and Apple Messages for Business should not be presented as interchangeable.
Native payment support in one channel does not establish payment support in another.
| Integration | What to validate |
|---|---|
| Apple Messages for Business | Business registration, customer entry points, approved capabilities and platform availability. |
| Hosted phone-number messaging | Number eligibility, sender/recipient capabilities, signed replies, number control and routing behavior. |
| SMS/RCS API | Carrier and country requirements, registration where applicable, eligible sender lines and receipt support. |
What Comms provides
Comms offers a hosted messaging API, signed inbound webhooks, a team inbox, optional agents and hosted MCP. Free is a shared test line with 100 messages/day. Plus is $50/month on a shared platform line. Dedicated is $200/month with $0 setup; it is a different plan with a dedicated number.
API line claiming requires workspace approval and available inventory. A denied claim returns line_claim_not_allowed; unavailable inventory returns no_available_line.
RCS requires a supported dedicated line, carrier enablement, and a compatible recipient. Sending currently supports one plain-text message to an E.164 phone number.
Porting requires approval and a supported number. Confirm port-in, port-out, geographic availability, fees, and timing before planning a migration. You can cancel replacement setup before submitting the transfer; a submitted transfer cannot be canceled from the setup panel.
AI usage is billed separately from messaging plans, through prepaid Comms credits or a connected customer OpenRouter account. No messaging plan includes AI usage. Review credit-purchase fees and model costs before enabling a hosted agent.
Run the same integration test on each provider
Use a consenting recipient and an eligible test line. Send a message with a stable retry identity, receive a reply, verify the webhook signature, replay an event, and reconcile a delivery receipt.
Test explicit channel failures and uncertain sends separately. An accepted request is not a delivered message.
For a SaaS integration, use two tenants and prove that a reply cannot reach the wrong tenant. Check human handoff, opt-outs, credential scopes and line offboarding. Ask each provider for number control, supported countries, throughput and service terms in writing.
Do not infer in-thread Apple Pay
Payment requests use checkout links only when the global Payments product and workspace payments are enabled and merchant requirements are met. Native in-thread Apple Pay is coming soon; checkout links are not native Apple Pay in Messages.
Comms checkout links and native Apple Pay are different capabilities. Test the current supported checkout flow and reconcile payment status through the payment integration.