How it works
There is no iMessage API.
There are three ways around that.
A plain technical account of why Apple keeps this closed, what the sanctioned programme actually covers, and how the services in the middle bridge the gap for everyone else.
01 / The closed door
Why Apple never shipped one
This is not an oversight that a feature request will fix. Every reason points the same direction.
End-to-end encryption is the product. iMessage content is encrypted between devices. A server-side API that composes messages on your behalf sits outside that model. Apple has consistently chosen the guarantee over the integration.
Spam would arrive instantly. iMessage is free to send and tied to a phone number or email. An open API would turn the highest-trust inbox on the platform into another marketing channel within a week, and the blue bubble would stop meaning anything.
The lock-in is deliberate. iMessage is one of the strongest reasons people stay on iPhone. Opening it to arbitrary senders — or to other platforms — reduces that. That is a commercial position, and Apple has defended it in court and in public.
Regulation is nudging the edges, not the centre. Interoperability pressure and the arrival of RCS have changed cross-platform messaging. Neither has produced a public endpoint for sending iMessages.
What about Messages for Business?
It is real, and it is genuinely sanctioned — but it is customer-initiated support messaging routed through approved partners, not an outbound API. If your goal is “remind 300 customers about Thursday”, it is the wrong tool.
Support
What Apple sanctions: customer-initiated
- Hi — is my repair ready?
- It is. Ready for pickup any time before 6pm today.Business replies to an inbound thread
Acme Auto
What businesses actually want: outbound
- Your repair is ready for pickup — open until 6pm.Requires a third-party API
02 / The three routes
Every solution in this space is one of these.
Once you can name the route a product is taking, its pricing, limits and failure modes stop being surprising.
Hosted API on managed Apple infrastructure
- Mechanism
- The provider operates the Apple-side sending infrastructure and fronts it with a normal REST API. You never touch a Mac, an Apple Account, or a bridge process.
- You supply
- An API key, an HTTPS request, and a webhook URL.
- Watch out for
- You are dependent on the provider's standing with Apple and on their rate limits. Pick one that is transparent about both.
The right answer for customer-facing messaging.
Self-hosted bridge on your own Mac
- Mechanism
- Software on a Mac signed into your Apple Account watches the Messages database and drives the Messages app to send. It exposes a local API you call over your network.
- You supply
- A Mac that never sleeps, an Apple Account you are willing to risk, and ongoing maintenance.
- Watch out for
- No SMS fallback, no business number separation, and consumer-account automation conflicts with Apple's terms.
Fine for prototypes and personal automation. Not for customers.
Apple Messages for Business
- Mechanism
- Apple's own sanctioned programme. Customers start a chat from Maps, Safari, or Search, and it lands in an approved messaging-service-provider platform.
- You supply
- An approved MSP partner, a review process, and a support-desk-shaped use case.
- Watch out for
- It is customer-initiated by design. You cannot use it to send an outbound reminder to a list.
Great for large brands with a support org. Rarely reachable for a 12-person business.
03 / The request lifecycle
What happens between your POST and their lock screen
Understanding the hops tells you where things go wrong, and which of those you can do anything about.
- 01
Your server sends
A POST with a recipient, a body, and an idempotency key. Always send an idempotency key — retries are inevitable and duplicate texts are expensive in goodwill.
- 02
The provider checks reachability
Is this number registered with iMessage? Providers expose this as a lookup so you can branch on it before you compose. Cache the answer, but not forever — people switch phones.
- 03
Routing decides the colour
Reachable → iMessage, blue bubble, no carrier fee. Not reachable → SMS fallback over a carrier, green bubble, per-segment cost. This is the single most important line item in your bill.
- 04
Delivery status returns asynchronously
The POST response means accepted, not delivered. The real status arrives on your webhook seconds later. Systems that treat 200 as delivered report numbers that are quietly wrong.
- 05
The customer replies
Inbound hits your webhook. Check for STOP before anything else, then route the rest to whatever inbox a human actually reads.
- 06
The link gets tapped
No referrer travels with it. Your UTM parameters are the only thing connecting that session back to the message you sent.
import { after } from "next/server"; const STOP_WORDS = new Set(["stop", "unsubscribe", "cancel", "end", "quit"]); export async function POST(request: Request) { const raw = await request.text(); // 1. Never trust an unsigned webhook. This URL is public. if (!verifySignature(raw, request.headers.get("x-provider-signature"))) { return new Response("bad signature", { status: 401 }); } const event = JSON.parse(raw); // 2. Opt-outs are legally load-bearing. Handle them first, synchronously. if (event.type === "message.received") { const first = event.text.trim().toLowerCase().split(/\s+/)[0]; if (STOP_WORDS.has(first)) { await optOut(event.from); return Response.json({ ok: true }); } } // 3. Ack fast, work later — providers retry on slow responses. after(() => routeToInbox(event)); return Response.json({ ok: true });}04 / So which one
If the messages go to customers, use a hosted API.
That sentence covers roughly every small business reading this. The bridge route is a good way to learn the domain and a bad way to run a business.