messages.dev: The iMessage API for Agents, Explained
messages.dev is an iMessage API built for AI agents. You get a phone number backed by Mac hardware the company runs, and your code sends and receives blue-bubble messages through a REST API, a TypeScript SDK or a command-line tool. It’s a small, developer-first product based in the United Kingdom, launched in spring 2026, and it’s strict about one rule above all: people have to message your agent before your agent can message them.
The quick answer: messages.dev is one of the simplest ways to put an agent on iMessage. It has a clean SDK, a free sandbox you can use within minutes and a straightforward dedicated line plan. It’s also young, doesn’t name its team publicly, and offers no uptime SLA yet, so it suits building and early products more than anything mission-critical. A disclosure: we make Carly, which sells AI phone and texting agents to businesses, so there’s some overlap with what messages.dev customers build. We’ve stuck to facts from the company’s own pages.
messages.dev at a glance
Checked against messages.dev’s site, docs, terms, privacy policy and GitHub on November 12, 2026.
| messages.dev | |
|---|---|
| What it is | A managed iMessage API for AI agents, with SMS for non-iPhone recipients |
| Based in | United Kingdom |
| Launched | Spring 2026 (SDK first published April 2026) |
| Plans | Free sandbox (50 messages a day), dedicated line at $99 per month, Enterprise custom |
| Developer access | REST API, TypeScript SDK, messages-dev CLI, signed webhooks |
| Sending rule | Contact-first: recipients must message your line before you can send to them |
| Uptime SLA | None at launch, per its terms |
| Best for | Developers prototyping or running early-stage agents on iMessage |
How messages.dev works
Apple doesn’t offer a public iMessage API, so every service in this category runs real Apple hardware. messages.dev’s terms say so directly: it operates “the Mac hardware, Apple IDs, and carrier connections that back each Line” on your behalf. It also states that it “is not affiliated with, endorsed by, or sponsored by Apple Inc. or any mobile carrier.”
A line can be a phone number or an Apple ID, and messages and events identify each side by one or the other. Sending is asynchronous. You post a message and get back an outbox ID, then the message moves from pending to claimed to sent, or to failed with a reason. You can track that by webhook or by polling.
The API covers what an agent needs for a natural conversation:
- Messages and group chats, with one attachment per message.
- Audio messages, uploaded in common formats (m4a, mp3, wav and others) and sent as iMessage audio messages, with conversion handled on the server.
- Tapback reactions, typing indicators and read receipts, both sent and received.
- Seven webhook events: message received, message sent, reaction added and removed, read receipt, and typing started and stopped. Each is signed with an HMAC signature and replay protection.
API keys can be limited to specific lines and given only the scopes they need, such as read-only access to messages. One caveat from the docs: some lines don’t have “advanced features” enabled, and sending audio messages, reactions, typing indicators or read receipts from one of those returns an error. Ask which lines you’ll get.
The contact-first rule
This is the design decision that shapes everything else. Outside the sandbox, the docs say you can only send to a contact or group chat “after they have messaged your line first.” Sending to someone cold returns an error, and the docs don’t mention any plan that lifts the rule.
In practice, your agent needs a way for people to start the conversation: a “text us” button, a QR code, a phone number printed on a receipt, or an sms: link that opens Messages with the first message filled in. Once someone writes in, replies within 24 hours of their last message are effectively unlimited.
messages.dev frames the rule as protection for your line. Apple doesn’t publish its spam thresholds, and lines that send to strangers get flagged. The company’s position is that inbound-first conversation “stays comfortably under those signals.”
Per-line limits
messages.dev publishes a set of recommended operating limits. Only the API request rate is enforced. The rest, its docs explain, reflect “Apple’s unpublished thresholds,” and going past them “raises the risk of Apple silently throttling or banning the underlying line.”
| Limit | Value |
|---|---|
| Throughput per line | 1 message per second |
| New contacts who texted in, per day | 1,000 |
| Replies inside a 24-hour conversation window | Unlimited |
| Follow-ups to contacts quiet for over 24 hours | 200 a day |
| Unanswered messages to one contact | 5 |
| Healthy outbound-to-inbound ratio | 10 to 1 or lower |
| API requests per hour per key | 1,000 |
The docs list the signals Apple watches: the ratio of messages sent to received, unanswered messages on a thread, volume combined with low recipient diversity, and spam reports. That last one is the sharpest: “A handful of ‘Report Junk’ taps on a single line can trigger restrictions within hours, with no appeals process.”
The sandbox and plans
Every account comes with a sandbox line, a shared iMessage number owned by messages.dev. You activate it by texting a code from your own phone, which pairs that phone to your account. From then on you can send up to 50 messages a day to your paired phone only, with reactions, typing indicators, read receipts and webhooks all working. The budget resets at midnight UTC and is shared across all your API keys.
| Plan | Price | What you get |
|---|---|---|
| Sandbox | Free | 50 messages a day to your own paired phone, full API and SDK, webhooks |
| Line | $99 per line per month | A dedicated phone number, unlimited messages, managed infrastructure, Slack support |
| Enterprise | Custom | Multiple lines, volume discounts, priority support, custom SLAs, dedicated infrastructure |
Prices are from messages.dev’s pricing page. “Unlimited messages” on a line still sits inside the per-line guidance above.
Developer experience
The developer tooling is where messages.dev puts its effort. The TypeScript SDK wraps every endpoint with typed methods, cursor pagination and typed errors. Its CLI sends messages from the terminal, lists chats, uploads files and manages webhooks. Its most useful command is listen --forward-to, which streams your account’s live events to a local URL with the same signatures production webhooks use. That lets you build and test a webhook handler on your laptop without exposing a public URL.
messages.dev also publishes an llms.txt file that puts authentication, every endpoint and every webhook payload in one document, which suits developers who build with AI coding assistants.
Terms, data and maturity
Read messages.dev’s terms and privacy policy, both last updated April 29, 2026, with a few points in mind:
- No uptime SLA. “We do not offer a formal uptime SLA at launch,” the terms say, and delivery “depends on Apple’s iMessage network, mobile carriers, the state of recipient devices, and conditions outside our control.”
- Lines can be suspended. messages.dev may suspend your access or an individual line “if a carrier or Apple flags activity on a Line.”
- Message content is stored. The privacy policy says it stores “the full text of messages sent and received through your Lines,” along with phone numbers, Apple IDs, reactions and attachments, for as long as your account is active. Queued outbound messages are deleted within 24 hours of delivery or failure.
- You can take your data with you. When an account closes, you can export your data through the API for up to 30 days before deletion.
On maturity, the public signals are modest. The TypeScript SDK was first published in April 2026 and is at version 0.2.0. Its two public GitHub repositories were last updated in May 2026. The site doesn’t name the people behind the company, and we found no independent customer reviews or launch coverage. None of that says the product doesn’t work. It does mean you should test it with your own traffic before committing.
How messages.dev compares
Each managed iMessage provider has a different emphasis:
- messages.dev: a lean developer API with a firm inbound-first rule.
- Linq: the infrastructure behind many consumer assistants, including Poke and Tomo, with managed load balancing across lines.
- Blooio: self-serve lines for small businesses and agencies, plus Apple Messages for Business.
- Photon: open source, and one codebase that also reaches WhatsApp and Telegram.
- Chert: iMessage plus FaceTime audio and video calls for agents.
Who messages.dev suits
It’s a good fit if:
- You’re a developer who wants to get an agent texting on iMessage this afternoon, starting with a free sandbox.
- Your users will always text first, for example an assistant people sign up for and save as a contact.
- You value a typed SDK and good local tooling over a long feature list.
Look elsewhere if:
- Your agent needs to start conversations with people who haven’t texted it.
- You need an uptime commitment or a published security certification.
- You want to know who you’re contracting with before you send customer conversations through them.
And if what you need is an AI that answers your own business line and texts customers back, rather than infrastructure for building one, Carly does that out of the box. Add it to ChatGPT or Claude, get a business number, and its agents answer calls, follow up on missed calls by text and reply on WhatsApp. It uses standard SMS rather than iMessage. Our guide to AI text messaging shows what that looks like.
FAQ
What is messages.dev?
messages.dev is a UK-based iMessage API for AI agents. It runs the Mac hardware and Apple IDs behind each line and gives developers a REST API, TypeScript SDK and CLI to send and receive iMessages.
Is messages.dev free?
There’s a free sandbox with 50 messages a day to your own paired phone. A dedicated line for production is $99 a month.
Can messages.dev send the first message?
No. Outside the sandbox, a contact or group chat has to message your line before you can send to them. Sending to someone who hasn’t returns an error.
Does messages.dev support group chats and reactions?
Yes. It supports group chats, tapback reactions, typing indicators and read receipts, though some lines need advanced features enabled for reactions, typing, read receipts and audio messages.
Does messages.dev have an SLA?
Not at launch. Its terms say it doesn’t offer a formal uptime SLA, though Enterprise plans list custom SLAs.
Who owns messages.dev?
The site and terms describe messages.dev as a company based in the United Kingdom but don’t name its founders or team.
Ready to automate your busywork?
Carly schedules, researches, and briefs you—so you can focus on what matters.
See what people say
"Before Carly, I relied on a Calendly link, but the whole process felt impersonal and not very professional. Carly changed that by handling all the back-and-forth, so I'm no longer stuck in endless email threads trying to line up schedules.
Now Carly reaches out to candidates, shares my real-time availability, lets them pick a slot, then sends a Zoom link and drops it straight into my calendar. She sends reminders to both of us before each call, which has significantly reduced no-shows and last-minute confusion.
On top of scheduling, Carly acts like a full executive assistant, sending me my schedule the night before so I can prepare for each call. It reminds me of the old x.ai assistant, but Carly is noticeably smarter, faster, and better suited to my healthcare recruitment business."
