The phrase 'third-party POST API' is an unusually precise description of this category, because it names the two things that matter: it is an ordinary HTTP POST, and it is third-party. There is no first-party option — see does Apple have an iMessage API.
The shape, which is nearly universal
Every hosted vendor has converged on roughly the same request. Learn it once and you can read any of their documentation in a couple of minutes.
curl -X POST https://api.example-provider.com/v1/messages \ -H "Authorization: Bearer $IMESSAGE_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "to": "+15551234567", "text": "Your appointment is confirmed for Tuesday at 2pm." }'| Concern | Common shape | Varies how |
|---|---|---|
| Auth | Authorization: Bearer <key> | Some scope the key per line or project |
| Path | POST /v1/messages | Occasionally /send or /messages/send |
| Body field | text | Also seen as body, message, content |
| Recipient | to, in E.164 | Some accept a conversation id instead |
| Response | { id, status } | Status vocabularies differ meaningfully |
| Errors | 4xx/5xx with JSON | Rate-limit headers are inconsistently present |
Wrap it, because the differences are exactly where a migration hurts
A thirty-second send(to, text) wrapper turns those inconsistencies into one file. Given how young these vendors are, that is the highest return-on-effort decision in the whole integration — see switching providers.
The half that is not a POST
Sending is a POST you make. Receiving is a POST somebody else makes to you — an inbound webhook hitting an endpoint you host. That half is where integrations actually break, because delivery is at-least-once and duplicates are routine.
Photon is the exception worth knowing about: it uses a persistent gRPC stream rather than webhooks, so there is no endpoint for you to host and secure. Whether that is simpler depends entirely on whether your infrastructure likes long-lived connections.
Working implementations of both halves are in Node.js and Python; the full API reference view is in iMessage API documentation.
Related questions
- Can I POST to an iMessage API?
- Yes, to a third-party provider's endpoint. Sendblue, Blooio, LoopMessage, Linq and Photon all accept an HTTP POST with a recipient and a message body. Apple publishes no endpoint of its own.
- Is there a standard iMessage REST API?
- No standard exists, because there is no specification to standardise against. Vendors have converged on a similar shape — bearer token, POST /messages, `to` and `text` — but field names and error semantics differ.
Still deciding?
Compare the services that can actually send this on the providers page, see what each one costs, or read the step-by-step guides.