"Free iMessage API" is a common search and it has an honest answer: the free options all require a Mac you own, an Apple ID you own, and your continued attention. That is not a criticism of the projects — several are very good — but it is the boundary of what open source can do here, and it follows directly from Apple never having opened the door.
The categories
| Category | What it does | Good for | Not good for |
|---|---|---|---|
| Self-hosted bridge | Turns a Mac into an HTTP server in front of Messages | Personal automation, hobby bots, a second inbox | Business messaging, uptime, multiple senders |
| Database reader | Reads chat.db on macOS | Analysis, exports, archiving | Sending anything at all |
| Protocol bridge | Connects iMessage to Matrix or another network | Unified personal messaging across platforms | Anything commercial |
| AppleScript wrapper | Scripts the Messages app | One-off notifications to yourself | Delivery confirmation, replies, scale |
BlueBubbles
The most complete open-source project in the space. A server component runs on a Mac and exposes a real API with webhooks; clients exist for Android, Windows, Linux and the web. Its actual purpose is to let someone with an iPhone use iMessage from a non-Apple device, and it does that well.
Developers reach for it as a free API, and it can serve as one — but you inherit the Mac, the Apple ID, the network, the OS updates and the on-call rota. The full comparison against a paid line is here.
Matrix bridges
The mautrix-imessage project bridges iMessage into Matrix, and can run on top of a BlueBubbles server rather than requiring direct access to a Mac's internals. If you are already running a Matrix homeserver and want iMessage in it, this is the mature option.
It is architecturally a personal-messaging tool. Building business messaging on it means treating a puppeting bridge as production infrastructure, which is a lot of moving parts between your application and a customer's phone.
Database readers and exporters
A family of tools — in Python, Rust and Swift — that open the SQLite database macOS keeps at ~/Library/Messages/chat.db and turn it into something queryable. They read; they do not send.
For the question "how many of the customers I texted manually last quarter actually replied?", these are exactly right and nothing commercial does it better. Give the terminal Full Disk Access first, or the file is unreadable and the error message will not tell you why.
Where the free path ends
The five things no open-source project gives you
A business phone number separate from a personal Apple ID. Someone else's uptime rather than your Mac's. SMS or RCS fallback when the recipient is on Android. Someone to call when the line stops delivering. And an account that was not designed for personal use — which matters, because sending business volume from a personal Apple ID is how accounts get restricted, and an Apple ID restriction is not confined to Messages.
That last point is the one most often skipped. The Apple ID doing the sending is usually somebody's real Apple ID, attached to their photos, their purchases and their devices. The blast radius of a restriction is much larger than a failed campaign.
Reading a project before you depend on it
- Last commit date. This ecosystem breaks with every macOS release. Six months of silence means it is probably broken on current macOS.
- Open issue titles. Search them for the macOS version you are on. Someone has already found the breakage.
- Whether it needs SIP disabled. Some approaches require turning off System Integrity Protection, which is a security decision, not a configuration step.
- Licence. Several projects in this space are AGPL. If you are wrapping one inside a commercial product, read it properly.
- Whether it sends or only reads. A surprising number of "iMessage API" repositories are read-only, and the README does not always lead with that.
The honest recommendation
- Sending yourself alerts? AppleScript. Ten minutes, zero dependencies.
- Want iMessage on your Android phone? BlueBubbles. That is the problem it was built for.
- Analysing your own message history? A
chat.dbreader. - Running a business on it? A paid provider. The monthly fee is buying out of exactly the failure modes above, and the pricing is genuinely low at the entry level.
The free tools are not worse engineering. They are solving a different problem, and the boundary between the two problems is precisely the boundary Apple drew when it declined to ship an API. More on that.