DEV Community: Blooio – iMessage API

How to Send iMessages Programmatically (REST API, Python & Node.js)

David Harvey — Sun, 28 Jun 2026 03:45:08 +0000

If you've ever tried to send an iMessage programmatically, you've probably hit the same wall everyone does: Apple has no public iMessage API. There's no POST /imessage in the developer docs, no SDK, no OAuth scope. Yet "blue bubble" delivery has 3–4× the open rates of SMS, so the demand to send iMessages from code — for CRMs, bots, notifications, and outbound — keeps growing.

This guide covers the realistic options, then walks through actually sending and receiving iMessages over a REST API with working Python, Node.js, and curl examples you can paste and run today.

Why there's no official iMessage API

iMessage is a closed, end-to-end-encrypted protocol tied to Apple IDs and Apple hardware. Apple has never shipped a public API to send iMessages, and "Messages for Business" is a support-inbox product gated behind an approval process — not a way to send outbound messages from a script.

So historically, developers reached for hacks:

Approach	Works from a server?	Reliability	Receiving messages	Notes
AppleScript / `osascript`	No — needs a logged-in Mac with Messages open	Brittle	Polling the local SQLite `chat.db`	Mac-only, breaks on macOS updates
Shortcuts automation	No	Brittle	No	Manual, not built for scale
"Just use SMS" (Twilio etc.)	Yes	High	Yes	Green bubbles, no typing indicators/tapbacks/HD media
Hosted iMessage REST API	Yes	High	Yes (webhooks)	What this guide uses

The AppleScript route is fine for a one-off script on your own Mac. The moment you want to send from a server, send at scale, or receive replies reliably, you need a hosted API that manages the Apple side for you and exposes a normal HTTP interface.

The setup

For the examples below I'm using Blooio, an iMessage REST API. Any provider with a similar HTTP surface will follow the same patterns — the concepts (Bearer auth, a send endpoint, webhooks for inbound) are what matter.

You'll need:

An API key (Blooio gives you one in the dashboard — no credit card, no A2P/10DLC registration, no DUNS number)
A phone number you can test against

Base URL for all calls:

https://api.blooio.com/v2/api

Send your first iMessage (curl)

The whole thing is one authenticated POST. The chat is identified by the recipient's phone number (URL-encoded, because of the +):

curl -X POST \
  "https://api.blooio.com/v2/api/chats/%2B15551234567/messages" \
  -H "Authorization: Bearer sk_live_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{"text": "Hello from the command line 👋"}'

Response:

{ "message_id": "msg_a1b2c3", "status": "queued" }

That's it — no Mac, no AppleScript, no polling. If the recipient has iMessage, it lands as a blue bubble.

Send an iMessage from Python

The minimal version uses requests. Note the quote(..., safe='') on the phone number — forgetting to URL-encode the + is the #1 cause of silent 400s.

import os
import requests
from urllib.parse import quote

API_KEY = os.environ["BLOOIO_API_KEY"]
BASE_URL = "https://api.blooio.com/v2/api"

def send_imessage(to: str, text: str) -> dict:
    chat_id = quote(to, safe="")
    res = requests.post(
        f"{BASE_URL}/chats/{chat_id}/messages",
        headers={
            "Authorization": f"Bearer {API_KEY}",
            "Content-Type": "application/json",
        },
        json={"text": text},
        timeout=10,
    )
    res.raise_for_status()
    return res.json()

if __name__ == "__main__":
    result = send_imessage("+15551234567", "Hello from Python!")
    print(f"Message {result['message_id']} -> {result['status']}")

export BLOOIO_API_KEY=sk_live_your_key_here
python send.py

Send an iMessage from Node.js

Node 18+ has native fetch, so the basic case needs zero dependencies:

const API_KEY = process.env.BLOOIO_API_KEY;
const BASE_URL = "https://api.blooio.com/v2/api";

async function sendImessage(to, text) {
  const chatId = encodeURIComponent(to);
  const res = await fetch(`${BASE_URL}/chats/${chatId}/messages`, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ text }),
  });

  if (!res.ok) {
    throw new Error(`Blooio ${res.status}: ${await res.text()}`);
  }
  return res.json();
}

const result = await sendImessage("+15551234567", "Hello from Node.js!");
console.log(`Message ${result.message_id} -> ${result.status}`);

Blue bubble or green? Check capability first

Not every number can receive iMessage. If you're building an iMessage-first flow with SMS fallback, check capability before sending:

def has_imessage(phone: str) -> bool:
    chat_id = quote(phone, safe="")
    res = requests.get(
        f"{BASE_URL}/contacts/{chat_id}/capabilities",
        headers={"Authorization": f"Bearer {API_KEY}"},
        timeout=10,
    )
    if not res.ok:
        return False
    return bool(res.json().get("capabilities", {}).get("imessage"))

if has_imessage("+15551234567"):
    send_imessage("+15551234567", "Blue bubbles only ✨")
else:
    # fall back to your SMS provider here
    ...

Receiving iMessages (webhooks)

Sending is half the story — to build a bot or a two-way CRM thread you need inbound messages. Instead of polling, you register a webhook URL and the API POSTs events to you. Verify the HMAC signature so you only trust real events:

import express from "express";
import crypto from "node:crypto";

const app = express();

app.post(
  "/webhooks/blooio",
  express.raw({ type: "application/json" }),
  (req, res) => {
    const signature = req.header("x-blooio-signature") ?? "";
    const event = req.header("x-blooio-event") ?? "";
    const secret = process.env.BLOOIO_WEBHOOK_SECRET;

    const expected = crypto
      .createHmac("sha256", secret)
      .update(req.body)
      .digest("hex");

    const ok = crypto.timingSafeEqual(
      Buffer.from(expected),
      Buffer.from(signature),
    );
    if (!ok) return res.sendStatus(401);

    const payload = JSON.parse(req.body.toString("utf8"));

    if (event === "message.received") {
      const { from, text } = payload.data;
      console.log(`${from}: ${text}`);
      // ...reply, route to your CRM, trigger an LLM, etc.
    }

    res.sendStatus(200);
  },
);

app.listen(3001, () => console.log("Listening on :3001"));

For local development, tunnel the endpoint with ngrok and point the webhook at the tunnel URL. Now you have a full send + receive loop — enough to build an iMessage bot.

Automating without writing code

If you'd rather wire iMessage into existing tools than write a service, the same API drops into no-code/low-code platforms. Blooio has native nodes/actions for n8n, GoHighLevel, HubSpot, and Zapier — so "new lead in CRM → send iMessage" is a couple of clicks rather than a deploy.

Gotchas worth knowing up front

URL-encode the phone number. +15551234567 must become %2B15551234567. This bites everyone once.
No A2P/10DLC registration, DUNS, or campaign approval with a hosted iMessage API — that paperwork is an SMS/carrier thing. iMessage rides Apple's network.
Use idempotency keys for retries. Pass an Idempotency-Key header derived from your domain entity (e.g. order-123-shipped) so a retry never double-sends.
Throttle bulk sends. Don't fire 1,000 parallel requests — cap concurrency (e.g. p-limit in Node, a semaphore in Python) and back off on 429.
iMessage ≠ guaranteed. If a number isn't on iMessage, check capability and fall back to SMS rather than assuming a blue bubble.

Wrapping up

You don't need a Mac mini farm or fragile AppleScript to send iMessages programmatically anymore. A hosted iMessage REST API turns it into a normal HTTP call — POST to send, webhooks to receive — that works the same from Python, Node.js, curl, or your automation tool of choice.

If you want to try the exact examples above, you can grab a free key (no credit card, no A2P registration) and read the full reference here:

What are you building — a bot, a CRM integration, outbound? Drop it in the comments. 👇

SMS Pumping Is Draining Your 2FA Budget — and Mobile-Originated iMessage 2FA Fixes It

David Harvey — Sun, 28 Jun 2026 03:36:47 +0000

If you send SMS one-time codes, there's a decent chance you're paying scammers to phone-spam themselves on your dime. It even has a name: SMS pumping. And it's not a rounding error — Elon Musk claimed Twitter was losing ~$60M/year to fake 2FA traffic before they killed SMS 2FA for free accounts.

Here's how the scam works, why SMS 2FA is structurally expensive, and why flipping the direction — mobile-originated (MO) 2FA, taken to its logical end over iMessage — fixes both the cost and the fraud at once.

What is SMS pumping?

SMS pumping (also called AIT — Artificially Inflated Traffic, or SMS toll fraud) is a scheme where bad actors abuse a form that sends SMS one-time codes. They pump thousands of phone numbers — usually premium ranges they secretly control with a telecom — into your "send me a code" endpoint.

You pay for every one of those messages. A cut of that termination fee flows back to the fraudsters via the carrier. The "users" never log in. They were never users. The entire point was to make your verification endpoint dial a meter that pays them.

The structure that makes this possible is simple: you, the company, send (and pay for) the message. Every code is revenue for someone in the delivery chain — so there's a direct financial incentive to trigger as many as possible.

Why SMS 2FA is expensive even without fraud

Even with zero abuse, application-to-person (A2P SMS) is a bad cost curve:

You pay per message. Volume spikes — a launch, a bot attack, an international audience — turn into surprise bills.
International is brutal. Cross-border A2P carries steep carrier surcharges that vary wildly by destination.
Carrier fees and registration overhead. In the US you're funneled through A2P 10DLC registration, brand vetting, and per-segment fees before you send a single legit code.

So your 2FA line item is pay-per-event, unpredictable, and exploitable. Three bad properties for something that's supposed to be boring infrastructure.

The Twitter/X case

This isn't theoretical. When X announced it was removing SMS 2FA for non-paying users, the stated reason was fraud at scale:

A company that size could "fix" it by paywalling a security feature. Most teams can't — and shouldn't have to make 2FA a paid tier just to dodge a billing exploit.

The fix: flip the direction (mobile-originated 2FA)

Here's the key insight. SMS pumping only works because the company sends the message. That outbound, pay-per-code flow is the thing being gamed.

So flip it. In mobile-originated (MO) 2FA, the user sends a message to you to prove possession of their device. There's no outbound code to pump, no per-message payout to harvest, and nothing for a bot farm to monetize. The incentive that powers the entire scam disappears.

MO verification has been around (think shortcodes), but shortcodes are clunky, region-locked, and still cost money to provision. The modern version is much nicer.

Taking it further: reverse 2FA over iMessage

We built a live demo of this. Instead of us texting you a code to type back, you text a one-time code to us from your own iMessage — and we verify you the instant the message lands.

👉 Try it: demo.blooio.com/2fa

The flow:

Your app generates a short one-time code and a deep link that opens Messages with that code pre-filled.
The user hits send from their iMessage.
Blooio delivers an inbound message.received webhook. You match the code and read who sent it — verified.

Because the user sends from their own Apple ID over end-to-end-encrypted iMessage, it's spoof-resistant (unlike trivially-faked SMS sender IDs) and phishing-resistant (the user proves real possession instead of reading digits back to an attacker). And there's no outbound message to pump.

The code is almost embarrassingly small

Start a challenge, then let a webhook flip it to verified:

// 1. Start a challenge: generate a code + an iMessage deep link
app.post("/2fa/start", async (c) => {
  const code = newCode(); // short, unambiguous one-time code
  await store.create(code); // status: "pending"
  return c.json({
    code,
    // opens Messages to your Blooio number with the code pre-filled
    link: `https://start.msg.new/<your-handle>?text=${code}`,
  });
});

// 2. Blooio calls your webhook when the user texts the code in
app.post("/webhook/blooio", async (c) => {
  const event = await c.req.json();
  if (event.event === "message.received") {
    const code = extractCode(event.text);
    if (code) {
      // event.sender is the verified identifier (phone/email)
      await store.verify(code, event.sender);
    }
  }
  return c.json({ ok: true });
});

That's the whole trick: no outbound SMS, no per-code billing, no A2P registration. Just an inbound webhook and a string match.

SMS 2FA vs. reverse iMessage 2FA

	Reverse iMessage 2FA	Traditional SMS 2FA
Pricing	Flat monthly rate, predictable	Pay per message — spikes = surprise bills
Abuse	Can't be pumped (users message you)	Wide open to SMS pumping / AIT fraud
Cost at scale	Cheap, especially cross-border	Steep international + carrier surcharges
Security	E2E encrypted, tied to Apple ID	Sender IDs spoofable; SIM-swap exposure
Anti-phishing	User proves real possession	Codes get phished or relayed
Speed	Instant over WiFi/data	Often delayed, sometimes never delivered

How this actually saves you money

Predictable cost, not pay-per-event. A flat rate means a bot storm can't author your invoice.
Fraud incentive removed. No outbound code = nothing to pump = the $60M-style leak can't happen.
No A2P 10DLC / DUNS / carrier registration tax to start sending.
Cheaper internationally, where SMS surcharges hurt the most.

Try it / build it

Play with the live reverse-2FA demo: demo.blooio.com/2fa

If you want to build it into your own auth flow, Blooio is an iMessage API for developers — REST API, webhooks, and SDKs. Start free — no credit card, no A2P registration, no DUNS.