Before you evaluate an iMessage provider on features or price, read their API reference. It takes twenty minutes and it tells you things the marketing site is structured to avoid — how the platform actually behaves when something goes wrong, and how much of it was built after the launch announcement.
The first question: can you read it at all?
Some providers publish full documentation openly. Others put the reference behind a sign-in, or behind a sales call. That is a meaningful signal in itself — a gated API reference is a decision that you should be qualified before you are informed.
| Provider | Reference | Sandbox |
|---|---|---|
| Sendblue | Public, with documented request shapes | Free |
| Blooio | Public, publishes an OpenAPI specification | Free |
| LoopMessage | Public | Free |
| Miss Blue | Behind a sign-in | Free |
| Tuco AI | Onboarding-led; most deployments are configured for you | No |
| Linq | Public reference; sandbox behind signup | Trial |
| Photon | Public, SDK-first | Free tier |
An OpenAPI spec is worth more than a nicely designed docs site
Given a specification you can generate a typed client, diff it when it changes, and mock the whole API in tests without writing fixtures by hand. A handwritten docs page with pretty syntax highlighting gives you none of that, and drifts from the implementation without anyone noticing.
The five things to look up, in order
1. The error table
Find the list of error codes. If there is not one, that is your answer — a platform that has not enumerated its failure modes has not thought about yours. What you specifically want is a documented distinction between "this recipient cannot receive iMessage", "you are being rate limited" and "we are broken", because your retry logic depends on telling them apart.
2. Rate limits, in numbers
"Generous limits" is not a limit. You want a figure per minute and per day, and whether exceeding it returns a 429 or silently queues. Silent queueing is worse than an error: your system believes it sent something that is still sitting in a buffer forty minutes later. Why pacing matters.
3. The webhook payload, in full
Every event type, every field, and how the signature is computed. If signing is not documented, the endpoint is unauthenticated in practice, because you cannot verify what you cannot reproduce. What a correct handler looks like.
4. The awkward endpoints
Sending text is table stakes. The endpoints that reveal platform depth are the ones nobody builds first:
- Sending a reaction, and removing one. Removal in particular — it is a different Apple operation from adding, and support for it is a reliable tell for how deep the integration goes.
- Typing indicators, sent on demand rather than faked with a delay.
- Group threads — creating one, adding a participant, leaving. Much harder than one-to-one, and often missing.
- Attachments, with a documented size limit and a documented failure when you exceed it.
- Number lookup — is this recipient on iMessage — which saves you failed sends and, on metered plans, money.
- Message status by handle, so you can reconcile state without depending on a webhook you might have missed.
5. The changelog
A dated changelog tells you whether the platform is maintained and how breaking changes are handled. No changelog means you will find out about a breaking change from your own error rate.
What good looks like
Documentation checklist
- Full reference readable without an account.
- A machine-readable specification, not just prose.
- Enumerated error codes with retry guidance for each.
- Numeric rate limits, and the behaviour when you cross them.
- Complete webhook payloads plus the signing algorithm.
- A free sandbox with credentials you can get in under five minutes.
- A dated changelog.
- Copy-pasteable examples in at least
curlplus one language.
Five of eight is normal in this category. Fewer than four, and you are buying a service you cannot evaluate until you are already dependent on it.
What Apple's own documentation says
Worth being precise, because it is a common source of confusion: Apple publishes a great deal of Messages documentation on the developer site, and none of it lets you send an iMessage to a phone number from a server. Here is what each of Apple's Messages APIs actually does, and why the gap exists.