Questions we get
every week.

It still reaches them, automatically. The message falls back to RCS, or to SMS where RCS is not available, from the same number and with nothing for you to configure or switch on. So an Android customer is not a customer you cannot answer, and you do not keep a second number for them. It arrives as a green bubble with whatever that channel supports, which is why a read receipt or a typing indicator may not be there.

Every message records the service that carried it, so a thread tells you which channel each message actually used rather than leaving you to guess from a colour. You can also ask before sending: a lookup answers reachable, undeliverable, or unknown, from your own traffic rather than from Apple. Unknown means nobody has tried this handle yet, which is what every genuinely new customer looks like — it is a reason to send, not a reason to avoid it.

Yes. Images, video, PDFs, and voice notes all go through, and arrive as the real thing rather than a link — a voice memo plays in the thread the way one from a friend does. Attachments are fetched from the Mac that handled them, so what your customer sees is what was actually sent.

No. Miss Blue is messaging only: send, receive, react, unsend, typing indicators and read receipts. There is no voice or FaceTime.

Both, and both are deliberate acts rather than automatic ones. A read receipt puts "Read" under your customer's message on their phone, which is a claim that a person looked at it — so it is never sent by polling or by an automation. A typing bubble that appears and produces nothing for a minute reads worse than silence, so send one only when a reply is seconds away.

You can read and reply in group threads, and the console shows them as groups rather than as one person. Starting a new group from the API is not supported yet.

You can unsend inside Apple's two-minute window, exactly as you could from an iPhone. After that the message is delivered and stays delivered — the window is Apple's, not ours.

Yes, in both directions. A tapback your customer adds appears against the message it belongs to, and you can add or remove one from the API or the console.

Talk to us before you buy. Whether a particular number can be moved depends on where it lives today, and we would rather tell you no in a conversation than after you have paid. Most customers start on a number we provision, which is ready in days rather than weeks.

It is a dedicated line on hardware assigned to you — not a pool shared with strangers, and not a shortcode. The inbox is yours; we provide the interface your team reads it in. Shared-pool numbers exist as a separate, clearly-labelled option for people who want them.

One per line of conversation you want kept separate — a front desk and a recalls queue are two, not one. Numbers live inside projects, and who can answer which line is set per project by your own admins.

No, and this is enforced rather than discouraged. A line is capped at fifteen messages a minute, and anything past that is spaced four seconds apart instead of refused — so an ordinary busy conversation never notices, and a pasted list of five hundred contacts hits it immediately. Blasting is what gets numbers flagged, and a flagged number is one nobody's messages arrive from.

Conversations are unlimited. New people per line per day are not: aim at about thirty and we review anything well above it. That is not a billing lever — it is what keeps a number looking like a business rather than a broadcaster. If you need more reach, more lines is the answer.

The second one is refused with a 409 rather than delivered. A send takes a moment, and in that moment somebody unsure it worked presses send again — as does a retry after a timeout, and a second browser tab. Your customer receiving it twice is the one outcome nobody wants. If you genuinely mean to repeat yourself, there is a flag for it.

Yes, and a command line and an MCP server built from the same list of capabilities, so an agent can do exactly what a person can. Send, read threads, look a handle up, react, unsend, manage contacts and register webhooks. Keys are scoped to one project and nothing else.

A 201 means accepted, not delivered — delivery is a separate event that arrives afterwards, over a webhook or by reading the message back. Anything that failed shows up with the platform's own error against it, and every message records which Mac build handled it, so "did last Tuesday's failures stop after the update?" is a question with an answer.

That is what the MCP server is for. It is worth deciding deliberately what you let one do: replying is reasonable, and sending a read receipt is not — that receipt is a claim a human looked, and an agent that fires them by polling is telling a small lie at scale.

Whoever you put in the project. Numbers live in projects and people are added to projects, so a receptionist and a recalls clerk can share a workspace without sharing an inbox. Your own admins do this — you do not ask us every time somebody joins or changes desk.

Every conversation shows who on your team last answered it, and the activity screens show messages sent, people written to and days active per person. Conversations split by whether they replied, whether they are new, and who wrote first — because nine out of ten strangers ignoring a cold message is ordinary, and nine out of ten people who wrote in first being ignored is a problem.

Sends are refused with a 503 rather than accepted and lost, so a retry is safe and nothing silently disappears. Inbound messages that arrived while it was away are picked up when it reconnects.