# Blooio: a cloud iMessage, RCS and SMS API on rented Apple devices, and the limits that govern every send

slug: blooio · https://miscsubjects.com/a/blooio · category: reference · tags: imessage, messaging-api, blooio, vendor-reference · updated 2026-09-22T05:09:26.614Z

Blooio is a cloud service that sends and receives iMessage, RCS and SMS from a REST API, on Apple devices that Blooio owns and runs. A customer never touches a Mac or an iPhone: the customer rents a phone number, calls an HTTP endpoint, and Blooio's device fleet does the sending. Blooio's own description, read on 2026-09-21, is "an iMessage, RCS, and SMS automation platform for businesses" that delivers "native iMessages (blue bubbles), RCS, and SMS directly from your CRM or automation platform using dedicated phone numbers". Blooio's documents carry the constraint every such service lives under: a warning that an Apple ban on a number cannot be reversed.

Three terms carry the weight of what follows. A **line** is one phone number that Blooio has registered on iMessage and rents to one customer. A **shared line** is a number from a pool that several customers use, so the sending number can differ from message to message. A **dedicated line** is a number used by one customer only.

## The two API generations

Blooio runs two API versions side by side. Version 2 lives at `https://api.blooio.com/v2/api` and addresses every message by chat: a send is `POST /chats/{chatId}/messages` with `{"text": "..."}`, where the chat id may be a URL-encoded phone number for a one-to-one chat. Version 4, marked beta, lives at `https://api.blooio.com/v4` and adds a recipient in the body: `POST /messages` with `{"to": "+15551234567", "text": "Hello!"}`, sender chosen by the key's routing rules unless a `from` string pins it. Both take one header, `Authorization: Bearer bl_live_...`.

Counted from the two OpenAPI documents on 2026-09-21: v2 publishes 40 paths and 41 schemas; v4 publishes 68 paths, 101 operations and 59 schemas. The v4 additions over v2 are channels (`/channels`, with purchase, settings and profile), priorities (ordered sender lists per key), contact identities and merge, chat participants, attachments registered ahead of a send, message templates, API-key management, an events feed, and one inference endpoint, `POST /ai/bloobability/assess`.

## What one message can carry

A message on a Blooio iMessage line can be plain text, Markdown-styled text, attachments by URL, a carousel of 2 to 20 photos or videos, a poll with two or more options, a rich link whose title and image the sender overrides, a contact card that piggybacks on the next message, a Find My or Check In bubble, a calendar invite as an `.ics` file, or a custom bubble that points at the customer's own iMessage app extension by `bundle_id` and `team_id`. Reactions are tapbacks plus emoji on macOS Sonoma and later, sent with a `+love` or `-love` style string. Typing indicators, read receipts and per-chat background images have their own endpoints. Message effects (confetti, slam, invisible ink) are absent from the v2 and v4 specifications.

A send returns 202, not 200. The message starts at `status: queued` and `protocol: pending`, then resolves to `imessage`, `rcs` or `sms` within seconds, and moves through `sent`, `delivered` and `read`. Blooio's sending guide states the rule plainly: "Messages return 202, not 200". An `Idempotency-Key` header makes a retried send return the original response for 24 hours.

## Webhooks

Every event reaches the customer as one envelope: `{id, type, created_at, organization_id, data}`, where `data` carries the whole resource. Blooio's webhook reference says "`data` carries the fully-hydrated resource, so a consumer never has to call the API back to fetch it". Four headers ride on each delivery: `X-Blooio-Event`, `X-Blooio-Delivery`, `X-Blooio-Webhook` and `X-Blooio-Signature`, the last an HMAC-SHA256 over `{timestamp}.{raw_body}` in the form `t=<timestamp>,v1=<hmac>`. Event types documented on 2026-09-21: `message.queued`, `message.sent`, `message.received`, `message.delivered`, `message.read`, `message.failed`, `message.reaction`, `poll.received`, `poll.created`, `poll.voted`, `group.name_changed`, `group.icon_changed`, plus `safety.state_changed`, `number.purchase.completed`, `number.purchase.action_required`, `number.purchase.failed` and `number.removed` on v4. A subscription receives every type; filtering happens in the receiver. Deliveries are logged, replayable by id, and the signing secret rotates by one call.

## The safety engine that decides whether a send goes out

Blooio does not let a line send freely. Its messaging-safety guide opens with the reason: "Blooio applies safety limits to protect iMessage numbers from patterns that Apple may treat as automated or unwanted messaging." Two independent systems apply.

Conversation limits are per recipient. A new chat may receive 3 plain-text messages before the recipient answers; a reaction moves it to Acknowledged (3 per response); one written reply moves it to Active (4); three replies across two UTC days to Established (6); ten replies across three days in a thread at least seven days old to Trusted (8); fourteen silent days to Inactive (one re-engagement message). Links and attachments are unlocked only by a written reply. Blocked sends return 429 with a stable `code` such as `conversation_awaiting_reply`, and the guide says a retry timer will not clear them.

Number protections are per sending line and graduated: `queue` (bursts of up to 8, then a 3 to 8 second wait), `slow` (30 to 60 seconds), `pause_new` (no new chats), `reply_only`, and `review` (all sending stopped). The `one_way` reason fires when a line averages more than 10 new chats a day over three days, has at least 10 new chats in the trailing week, and fewer than 40% of them earned a written reply; `template` fires when at least half of 10 or more first touches in a week reuse one opener; `delivery` fires when the iMessage share drops more than 10 points or device-visible failures double against the 72-hour baseline; `sibling_ban` slows every other line for 72 hours after one line on the account is banned. Administrators may switch the limits off for a dedicated line; the guide labels that an exception that "materially increases the risk of an unrecoverable Apple ban".

## Numbers, plans and the purchase API

Prices published at blooio.com/pricing on 2026-09-21: Free Trial at $0 for 20 messages across 2 conversations; Starter at $39 a month on a shared line with 5 new contacts a day; Commercial Shared at $89 with 15 a day; Commercial Dedicated at $289 per line with no new-conversation cap; Inbound at $109 for a dedicated reply-only line that "cannot initiate new conversations"; Enterprise Dedicated from $389 for one line down to $195 per line at six or more. A custom area code costs $75 once. The pricing document's own summary: "All plans include full REST API access, unlimited team members, webhooks, native CRM integrations, an MCP server for AI agents, and no per-message fees." Voice calling, FaceTime on request, and call forwarding sit on the two dedicated plans.

Lines can be bought from code. The v4 Number Purchase API guide states: "The Number Purchase API lets you provision Blooio lines from your own code instead of clicking through the dashboard." Three gates precede the first purchase: organization identity verification through Stripe Identity, a staff-approved access request, and a card on file. `GET /channels/blooio/available?type=dedicated` returns masked inventory such as `(801) ***-****`; `POST /channels/blooio/purchases` with a required `Idempotency-Key` and a plan id (`shared_nc`, `shared_com`, `dedicated_com`, `dedicated_ent`, `inbound_basic`) returns 202 and a `purchase_id`; provisioning completes asynchronously and fires `number.purchase.completed`. A single order is capped at 10 lines by default, and a shared plan is capped at one line per organization. The same guide names resellers as an intended user: platforms that "provision a fresh number for each of their end customers".

## Routing across channels

A v4 API key owns channels: Blooio numbers, Twilio numbers imported with the customer's own Twilio account, WhatsApp Business sessions and RCS Business agents. A **priority** is an ordered list of those channels; entries on the same tier of the same type form a sticky pool, and lower tiers are fallbacks. Hybrid mode sends a cold first message on a Twilio SMS number and, after the contact replies, continues on a Blooio iMessage number with an optional transition sentence. SMS fallback for recipients without iMessage routes through the customer's Twilio sub-account, so A2P 10DLC registration stays where the customer already holds it.

## Developer surface

Beyond REST, Blooio publishes: a hosted Model Context Protocol server at `https://mcp.blooio.com/v4` exposing 61 tools on 2026-09-21 (from `me` and `send_message` to `replay_webhook_delivery` and `get_location_contact`), authenticated by the same API key as a bearer token or by OAuth; SDKs for Node, Python, Java and Go; an OAuth "Log in with Blooio" flow for third-party apps with scoped tokens, under which an app holding `apikeys:manage` can mint API keys for a customer organization and assign channels to them; `llms.txt`, `llms-full.txt` and `pricing.md` for machine readers; and native connectors for GoHighLevel, n8n, Make, Zapier, IFTTT, HubSpot, Clay and Whop.

## Inference

Bloobability v1.0.0, released 2026-09-02, is a pair of task heads on one 3.98-billion-parameter model built from Nemotron-3-Nano-4B. A caller sends a conversation plus named policies in plain language; the matcher returns which policies apply and which message ids support each, and the gauge returns a calibrated probability per policy. Blooio reports a matcher micro F1 of 0.9893 and a gauge median per-policy AUC of 0.8737 on held-out data.

## Claims Blooio makes about itself

Blooio's marketing figures, each carrying its own window: about 99% delivery across 4.2 million or more outbound iMessages and 310 or more active accounts, January to March 2026; roughly 2x the reply rate of SMS across 1,800 or more campaigns and 2.6 million messages, November 2025 to February 2026; a 99.9% uptime target with a contractual commitment only under a signed Enterprise order form; "SOC 2–aligned" controls rather than a published certification. Two absences are worth stating because the specifications, not the marketing, settle them: neither v2 nor v4 publishes a message-editing or unsend endpoint, and neither publishes a message-effect field. Whether a send lands as a blue bubble is decided by the recipient's device, and the `protocol` value on the message is the only place the answer appears.

## Sources

1. Blooio llms.txt (authoritative source notice) — https://blooio.com/llms.txt
2. Blooio API v2 index for machine readers — https://docs.blooio.com/llms.txt
3. Migrating from v2 to v4 — https://docs.blooio.com/migrating-to-v4
4. Blooio Pricing (markdown source of the pricing page) — https://blooio.com/pricing.md
5. Messaging safety limits and recovery — https://docs.blooio.com/guides/messaging-safety
6. Number Purchase API — https://docs.blooio.com/guides/number-purchase-api
7. Blooio MCP server card — https://blooio.com/.well-known/mcp/server-card.json
8. Blooio full context export, Webhook Events — https://blooio.com/llms-full.txt