DEV Community: amb.directory

Where an Apple Messages for Business chat starts

amb.directory — Thu, 15 Oct 2026 05:25:57 +0000

Customers do not install a separate app to message a brand on Apple Messages for Business. They start inside Messages, from a place the brand has registered.

Typical entry points:

A button or link on the brand's website
Apple Maps
A conversation URL
A QR code
Message Suggest, when Apple surfaces the brand

The customer starts the thread. Consented invitations are a narrower path, and they are not a substitute for those entry points. The two are written up separately:

The MSP still has to carry the conversation, including a handoff to a person. Provider capabilities are at amb.directory/msps.

Disclosure: I publish amb.directory.

What Apple checks before Messages for Business goes live

amb.directory — Thu, 15 Oct 2026 05:04:27 +0000

A brand does not flip Apple Messages for Business on by paying Apple. The account stays in test until Apple’s Experience Review passes.

The gates

An approved Messaging Service Provider. The brand does not connect to Apple directly.
An Apple Business Register account for the organization.
A conversation that includes a live agent during business hours. A bot-only flow does not pass.
Customer-initiated entry points. The channel is not for unsolicited outbound iMessages.
A built journey Apple can review: support, booking, commerce, or concierge, using the interactive features the MSP actually ships.

The approval write-up, including what Apple looks at in the review, is here: How to get approved for Apple Messages for Business.

The steps before that review, starting with Apple Business Register and MSP selection, are here: How to apply.

After the review

Once the account is commercial, customers can start from the website, Maps, and the other entry points the brand turns on. Patterns from brands that are already live are in best practices.

Disclosure: I publish amb.directory.

Apple Messages for Business is not an iMessage API

amb.directory — Thu, 15 Oct 2026 05:04:19 +0000

Most “iMessage API” products are a different system from Apple Messages for Business.

An unofficial sender uses Apple IDs or Macs to push blue-bubble messages. Apple Messages for Business is the channel inside the Messages app that a brand reaches through an approved Messaging Service Provider. It is how a customer starts a chat from a website, Apple Maps, Safari, or a Message Suggest result. It is not a public API key a brand calls on its own.

What a brand actually integrates

Apple does not give brands a standalone REST API. The MSP implements Apple’s server-to-server Messages for Business API. The brand connects to the MSP. Automation has to go through that MSP, with a live agent available during business hours, and the experience has to pass Apple’s Experience Review before it can go public.

The requirement list and the message flow are here: Apple Messages for Business API requirements.

Why the distinction matters

A blue-bubble sender will not put a business in Maps, will not add an Apple Pay button inside Messages, and will not survive Experience Review. If the job is customer-initiated support, booking, or commerce on iPhone, the path is an approved MSP.

A directory of those providers, compared by capability, is at amb.directory/msps.

Disclosure: I publish amb.directory, a directory of brands using Apple Messages for Business and the MSPs that implement the channel.

There is no public Apple Messages for Business API

amb.directory — Thu, 15 Oct 2026 01:49:49 +0000

Brands keep looking for an Apple Messages for Business API key. Apple does not issue one to brands.

The channel is real. A customer can message a business from the Messages app, Apple Maps, Safari, or a Message Suggest result. The integration is not a public REST API you call from your own backend. Apple requires an approved Messaging Service Provider. The MSP implements Apple's server-to-server Messages for Business API. Your brand connects to the MSP.

That split matters. Most products marketed as an "iMessage API" are a different system: unofficial senders that use Apple IDs or Macs to push blue-bubble messages. Those are not Apple Messages for Business, and they will not get a business into Maps or put an Apple Pay button inside Messages.

What public availability requires

Apple's onboarding rules put the gate on the MSP and on the experience, not on a developer token:

An Apple-approved Messaging Service Provider. Automation has to connect through that MSP.
An Apple Business Register account for the organization.
A conversation that includes a live agent during business hours. A bot-only flow does not pass review.
Apple Experience Review before the account moves from test to commercial.
Customer-initiated entry points. The channel is not for unsolicited outbound iMessages.

The requirement list, the message flow, and how CRM integration actually works (through the MSP's connectors, not an Apple CRM spec) is written up here: Apple Messages for Business API requirements.

Choosing an MSP

Apple keeps its own approved-provider list. The practical difference between providers is which interactive features they ship: list pickers, time pickers, Apple Pay, authentication, rich links, and a live-agent handoff. A capability-by-capability directory is at amb.directory/msps.

People ask about price in the same breath. Apple does not charge a per-message fee for the channel. The MSP does, and the number depends on seats, volume, and how much of the journey you integrate. The split is covered in Apple Messages for Business pricing.

If you are building the MSP platform rather than buying one, start with Apple's own docs:

Disclosure: I publish amb.directory, a directory of brands using Apple Messages for Business and the MSPs that implement the channel.
i