Does Apple have an official iMessage API?

The short answer

Apple does not publish a general-purpose API that lets a server send an iMessage from your number to an arbitrary contact. There is no public endpoint, no developer key for it, and no documented product that does that. This is the thing most people mean when they search for an iMessage API, and the answer has been no for the entire life of the platform.

Apple does publish two messaging developer surfaces. Neither is that. Understanding what each one is — and what it is not — explains the whole third-party market, including why providers charge what they charge.

What Apple actually publishes

There are two documented surfaces, and they solve unrelated problems. Conflating them is the source of most of the confusion in this topic.

Everything else marketed as an iMessage API is a third party operating Apple software on hardware somebody has to own.

• The Messages framework — build app extensions and sticker packs that run inside Messages on a user’s device
• Apple Messages for Business — a registered, reviewed customer-service channel with a documented REST API
• Nothing else — no public send API for an ordinary iMessage from an ordinary number

The Messages framework is not a send API

Apple’s Messages framework lets you build an iMessage app: an extension that appears in the Messages app drawer, or a sticker pack. Your code runs on the user’s device, inside their Messages app, at their initiation. It composes content into the conversation the user is already in.

It cannot start a conversation, cannot run on your server, cannot reach a contact who has not opened your extension, and cannot be driven by a backend workflow. If your goal is “send an appointment reminder from our CRM”, this framework is not on the path to it — it is a UI extension point, not a messaging channel.

Apple Messages for Business is real, and it is a different product

Apple Messages for Business — the product formerly called Business Chat — is a genuine Apple channel with genuine Apple documentation, including a Messages for Business REST API published at register.apple.com. Businesses do send and receive real messages through it, with rich interactive types like forms, list pickers, and Apple Pay.

But it is a branded customer-service channel, not a phone line. The conversation is with a registered business identity, not with a number. Apple controls the entry points — Maps, Safari, Search, Siri, and buttons the business places on its own properties — and the customer starts the conversation. You do not get to initiate outreach to a phone number you obtained somewhere else.

What Messages for Business requires

Getting in is a process, not a signup. A business registers through Apple Business Register using a business or managed Apple Account, accepts Apple’s terms, and completes an organization profile. Apple reviews the application, which its documentation describes as typically taking one to three business days.

During registration the business selects a Messaging Service Provider from Apple’s approved provider list. Providers receive an MSP ID identifying the platform, distinct from the business ID, plus a Base64-encoded Messaging API secret key that Apple’s documentation tells the registering agent to store securely and re-provision if it is compromised.

So even the official Apple channel routes most businesses through a third-party provider. It is not a case of Apple offering direct access and third parties existing because people did not read the docs.

• Business or managed Apple Account required
• Apple review, typically one to three business days
• MSP selected from Apple’s approved provider list
• MSP ID plus a Messaging API secret key issued on registration
• Customer-initiated entry points controlled by Apple
• A branded business identity, not a phone number

Why “there is no official API” keeps getting rediscovered

The question resurfaces constantly — in forums, in Reddit threads, in the phrasing of the searches themselves — because the premise is reasonable. Every other messaging channel has a send API. SMS has one, WhatsApp has one, RCS has one. iMessage is the conspicuous exception, and each new developer who needs it discovers the gap independently.

The gap is deliberate. iMessage is an end-to-end encrypted consumer service tied to Apple accounts and devices. A public server-side send API would make it trivially spammable and would sit awkwardly with the security model Apple documents for it. Messages for Business is the answer Apple chose instead: a separate, reviewed, identity-bound channel that keeps consumer iMessage as it is.

So what are third-party iMessage APIs doing?

Given no public send API, every provider in this market resolves the same way: real Apple software, signed into a real Apple identity, running on hardware somebody operates, with an HTTP interface in front of it. The API you call is theirs; the message is composed by Messages on a Mac.

This is worth stating plainly because it determines everything downstream — what can go wrong, what pricing has to cover, and what questions are worth asking. A provider is not reselling an Apple product; it is operating infrastructure on your behalf, and the quality of that operation is what you are buying.

• Apple devices or macOS instances signed into Messages
• An Apple identity per line, with its own account state
• A server-side API translating HTTP into on-device sends
• Inbound events read back out and delivered as webhooks
• Monitoring, recovery, and account health as an operational discipline

Self-hosted bridges versus managed providers

The same architecture is available as open-source software you run yourself. BlueBubbles runs a server on a Mac you keep awake; AirMessage takes a similar approach; OpenBubbles borrows a Mac’s hardware identity once and then talks to Apple directly. All are personal-use projects, and each puts a personal Apple account at the center of the design.

The trade is not price versus features. It is who is responsible at 3am when Messages logs out, macOS updates, the network path changes, or the account is throttled. For personal use that is an inconvenience. For customer conversations it is an outage with no support contract behind it.

What this means for your project

If you were hoping to find an Apple developer portal page with an iMessage send endpoint, stop looking — it does not exist, and the pages that appear to promise it are describing one of the two surfaces above. Decide instead which of three real paths fits.

Most business use cases land on the third. The first is only for in-Messages UI, and the second only works if your customers are the ones starting the conversation through an Apple entry point.

• Messages framework — an in-app experience inside Messages, on the user’s device
• Apple Messages for Business — a registered branded service channel, customer-initiated, via an approved MSP
• A managed third-party line — a business number you can send from and receive on, operated for you

Choosing between Messages for Business and a managed line

Choose Messages for Business when you are a recognizable brand running customer service at scale, your customers find you through Apple Maps or Search, you want Apple Pay and structured interactive message types, and you can absorb registration and review. It is the right tool for “customer taps Message on our Maps listing”.

Choose a managed line when you need to start conversations — sales follow-up, appointment reminders, service updates — or when you want a number rather than a brand identity, and you need it working this week rather than after a review cycle.

Questions worth asking any provider

Because every provider is operating infrastructure rather than reselling an Apple product, operational questions matter more than feature lists. The answers vary far more between vendors than the API surfaces do.

Ask the same set of everyone, and weigh the precision of the answers as heavily as their content.

• Is the line dedicated, and who owns the number if we leave?
• What happens when the Apple identity behind a line is throttled or logs out?
• What is the monitoring and recovery path, and who is paged?
• Are inbound events durable and replayable, or fire-and-forget?
• Are sends idempotent, and how are duplicates prevented?
• Is there a shared inbox where a person can take over a thread?
• What are the daily conversation limits, and why do they exist?

Read the primary sources

Two things make this topic unusually noisy: the answer is counterintuitive, and a lot of writing about it is produced by companies with something to sell — this page included. The primary sources are short and settle the question directly.

Apple’s Messages framework documentation describes the on-device extension surface. Apple Business Register hosts the Messages for Business documentation and REST API specification, including registration and MSP requirements. Between them, the boundary of what Apple offers is unambiguous.