How to send an iMessage programmatically

The question is simple: a thing happened in your system — an order shipped, an appointment was booked, a lead filled in a form — and you want an iMessage to go out without a human opening Messages and typing it.

Apple does not sell that. There is no endpoint, no SDK, no entitlement you can apply for. The full explanation of why is here, but the practical consequence is that every method below is a workaround of some kind, and they differ enormously in how much weight they will hold.

The four methods, ranked by durability

Method 1: AppleScript on a Mac

The answer every search returns first. macOS exposes the Messages app to AppleScript, so a script can hand it a recipient and a body and tell it to send.

on run argv
  set recipientNumber to item 1 of argv
  set messageBody to item 2 of argv

  tell application "Messages"
    set targetService to 1st account whose service type = iMessage
    set targetBuddy to participant recipientNumber of targetService
    send messageBody to targetBuddy
  end tell
end run

Call it from Node with child_process, from Python with subprocess, from cron, from anything. It genuinely works, and for sending yourself a build notification it is the correct answer.

Method 2: a self-hosted bridge

Projects like BlueBubbles turn a Mac you control into a small server with a real HTTP API and webhook callbacks in front of the Messages database. It is a genuine upgrade over raw AppleScript: you get message IDs, inbound events and a queryable history.

It is still your Apple ID, your hardware, your uptime and your problem at 2am. The full comparison against a paid API is here, along with the wider open-source landscape.

Method 3: a third-party REST API

This is what people mean by "an iMessage API". A provider runs the Apple infrastructure — real accounts, real devices, in a data centre — assigns you a phone number, and puts an HTTP interface in front of it. You send a request; a blue bubble arrives.

curl --request POST 'https://api.sendblue.co/api/send-message' \
  --header 'sb-api-key-id: YOUR_SB_API_KEY_ID' \
  --header 'sb-api-secret-key: YOUR_SB_API_SECRET_KEY' \
  --header 'Content-Type: application/json' \
  --data-raw '{
    "number": "+19998887777",
    "content": "Your 2pm window is confirmed.",
    "status_callback": "https://acme.co/webhooks/imessage"
  }'

What you are buying is not the HTTP call — you could write that yourself. It is the number, the delivery signal, the inbound webhook, the SMS fallback when the recipient is on Android, and somebody else being responsible for keeping the line alive. Which provider and what it costs are separate questions.

Method 4: Apple Messages for Business

Apple's own programme, and the only officially sanctioned way to hold an iMessage conversation as a business. The catch is structural rather than technical: the customer has to start the conversation. You cannot send the first message. The full guide to what it does and does not allow is here.

Choosing between them

If none of them are true, AppleScript is free and you should use it. The cost of a paid line is not the message — it is buying out of the failure modes above.

The first thing to build

1. 1Open a free sandbox with any provider that offers one — four of the five we cover do.
2. 2Send one message to your own phone with curl. Confirm it is blue.
3. 3Point status_callback at a request-bin URL and watch the delivery events arrive.
4. 4Reply to yourself from the phone and watch the inbound webhook fire.
5. 5Only then wire it into your application — from Node or Python.

Four curl commands tell you more about a provider than an hour on their marketing site. Do them before you write an integration, not after.