# LoopMessage: an iMessage, SMS, RCS and WhatsApp carrier API metered by daily contacts

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

LoopMessage is a cloud messaging service that sends iMessage, SMS, RCS and WhatsApp through one API from sender identities it manages, and it describes itself as a carrier: "Omnichannel messaging carrier for businesses and AI assistants. Send iMessage, SMS, RCS and WhatsApp through one API and reduce communication costs." The customer does not run a Mac or an iPhone. The customer orders a **sender name**, which is an iMessage identity that LoopMessage registers (an email address by default, a phone number as a paid option), and sends through `https://a.loopmessage.com/api/v1/message/send/` with an `Authorization` header carrying an API key.

Two more terms matter. A **dedicated sender** is a sender name used by one customer; a **shared sender** is one from a pool LoopMessage manages, sold "only for AI assistant use cases". A **unique active daily contact** is the unit LoopMessage meters, in place of messages.

## The send call

One endpoint carries every send. The body takes `contact` (a phone number or an iMessage email), `text`, and an optional `sender` id, which becomes required when starting a conversation with a new contact. Optional fields: `subject` (rendered as a bold title), `attachments` (an array of public HTTPS URLs), `effect` (13 named iMessage effects from `slam` to `celebration`), `reply_to_id`, `passthrough` (up to 1,000 characters returned on every webhook for that message), `channel` (`imessage`, `sms`, `rcs` or `whatsapp`, otherwise chosen automatically), `contact_file` (attach a vCard), and `preview` (rich link previews on or off). The same endpoint sends into an iMessage group. Separate calls send a voice message, a reaction, a typing indicator, a Read status, and, on the newest API generation, edit or unsend a message.

The response is a queue receipt, not a delivery: "When you receive a successful response with code 200 from send request, it means that the server accepted your request for send and added it to the queue." Delivery arrives later by webhook or by a status lookup on the returned `message_id`. Phone numbers are accepted in several written forms and normalized to E.164.

## Webhooks

LoopMessage posts JSON to a URL registered per organization and expects a 200 within 15 seconds; anything else is retried. Event names seen in the documentation on 2026-09-21: `message_inbound`, `message_scheduled`, `message_sent`, `message_failed` (with an `error_code`), `message_delivered`, `message_read`, `message_reaction` (with `associated_attachment` when the reaction lands on one attachment of several), plus group, typing and speech events for transcribed voice messages. A webhook-history page in the dashboard shows past deliveries.

## Sending first, and the limits

LoopMessage's pricing page answers the question it expects most: "Is it possible to send an outbound text first?" Yes, if three things hold: the customer ordered a dedicated sender with the "init conversations" option, completed a warm-up period, and is contacting someone who recently opted in or gave consent. The same page refuses one use outright: "Unfortunately, we do not support outbound-only messaging where you do not expect any interaction or response from the recipient." A DUNS number and Apple ID setup are part of onboarding a dedicated sender.

Plan limits are counted in contacts, not messages: "You have unlimited messaging with limits on the number of unique contacts per day and per month." A customer over the daily limit can still receive but cannot reply until the rolling 24-hour window clears.

## Plans and prices

From loopmessage.com/pricing on 2026-09-21. Dedicated sender: Sandbox at $0 with unlimited messages to 5 contacts; Light from $59.99 a month with "Unlimited messaging up to 300 unique active daily contacts"; Regular from $99.99 a month up to 1,000. Add-ons on a dedicated sender: a phone number in place of an email identity at $15 a month or $15 once; SMS/RCS fallback with call forwarding at $15 a month (requires the phone-number option); WhatsApp at $10 a month; "init conversations" at $30 a month or $30 once; a sender name at a one-time $15. Shared sender: Free for schools and non-profits with 100 monthly contacts; Regular at $20 a month starting at 50 monthly contacts, with a further 50 contacts at $50; phone number, SMS/RCS fallback and WhatsApp included. Bulk discounts start at 3 senders. Payment by card in any currency or by wire.

## Beyond the send endpoint

The documentation index lists an audience (contact) store, campaigns, message history, organizations, sender pools, an embedded inbox, paid content, sign-up forms, deferred (scheduled) messages, an S3-bucket option for attachment storage, a Twilio API adapter, and a Model Context Protocol server at `https://mcp.loopmessage.com/mcp` that serves documentation search only, not sending. Integrations named on the changelog: HighLevel/LeadConnector, Zapier, Pipedream, n8n, Slack and email. Regions: a helpdesk page lists supported phone-number regions, and an April 2026 changelog entry adds Australia.

## Compliance as LoopMessage states it

A helpdesk page titled "Is it Apple authorized API?" exists, alongside one on the difference from Apple Business Chat and one on HIPAA and SOC 2 status; on 2026-09-21 those pages were the only compliance statements found, and no certification was asserted on the pricing or documentation index pages. Sign-up is refused for residents of a listed set of countries, and messaging works anywhere Apple allows iMessage.

## Sources

1. LoopMessage llms.txt — https://loopmessage.com/llms.txt
2. LoopMessage Sending Messages — https://loopmessage.com/apidocs/send-message
3. LoopMessage pricing — https://loopmessage.com/pricing
4. How the pricing plan limits work? — https://loopmessage.com/helpdesk/pricing-plan-limit
5. LoopMessage MCP — https://loopmessage.com/apidocs/mcp


---

# Linq: an iMessage, RCS, SMS and voice API for AI agents, with its limits, webhooks and retention modes

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

Linq is an iMessage, RCS, SMS and voice API sold to teams that build AI agents, run on Apple hardware that Linq operates. Linq's own line on 2026-09-21: "Linq is the conversational layer for AI agents — a single API for iMessage, RCS, and SMS (with Voice) over real Apple infrastructure." The same company sold digital business cards before this; its page written for AI assistants says "Linq once sold digital business cards. Linq has pivoted." Everything below concerns the messaging API, reached at `https://api.linqapp.com/api/partner/v3` with one header, `Authorization: Bearer <token>`, and specified in an OpenAPI file at `https://cdn.linqapp.com/openapi/linq-api-v3.yaml`.

Three terms carry the rest. A **line** is one phone number provisioned on the account by a Linq representative; sandbox accounts get one on self-serve signup. A **handle** is a phone number in E.164 form or an email address. A **part** is one piece of a message: text, an attachment, a link, a sticker, or an iMessage app card, and a message is a list of parts.

## What the API sends

Linq's capability table names unified sending across iMessage, RCS and SMS with automatic or explicit protocol selection; attachments up to 100 MB; group chats with participant add, remove and leave; threaded replies; tapbacks plus any Unicode emoji as reactions; message effects; typing indicators sent and received; polls; chat backgrounds in color, animated or photo form; and webhooks. Its documentation, read in full on 2026-09-21, adds voice memos through a dedicated endpoint, stickers in three forms (peeled onto a message, sent alone, or placed inline in text), mentions of one participant in a group, message editing by `PATCH` with a `message.edited` event, rich link previews, iMessage app messages, "experiences" that render as native cards inside Linq's own iMessage app, location sharing, contact cards, blocked handles, capability checks for iMessage and RCS, and payment links plus an "Agentcard" flow in which an agent pays on a customer's behalf with a one-time card.

Effects are an object, `"effect": { "type": "screen", "name": "confetti" }`, with 11 screen effects and 4 bubble effects listed. Chat health is scored per chat as HEALTHY, AT_RISK, CRITICAL or OPTED_OUT, and a beta phone-reputation score exists per line.

## Limits

Linq's rate-limit page states: "We recommend limiting message volume to a combined total of up to **7,000 inbound and outbound messages per day per line**." There is no hard daily cap outside sandbox accounts, which get 100 messages a day. A hard limit applies per pair: 30 messages per 60-second window for each sender–recipient pair, returning 429 with error code 1007 and a `Retry-After` header. Capability checks run at most once per 10 seconds. Every error body carries a numeric `code`, a `message`, the HTTP `status`, a `doc_url` and a `trace_id`; the code list on 2026-09-21 runs from 1001 (missing field) through 2031 (no active location share) into 3xxx server and 4xxx delivery errors.

## Webhooks

An envelope carries `api_version`, `webhook_version` (`2025-01-01` or `2026-02-03`), `event_type`, `event_id`, `created_at`, `trace_id`, `partner_id` and `data`. Message events are `message.sent`, `message.received`, `message.delivered`, `message.read`, `message.failed` and `message.edited`; Linq's comparison page counts 44 event types in all, across messages, chats, groups, reactions, typing, payments and location. Signatures follow the Standard Webhooks scheme, and the docs tell the receiver to re-fetch the resource after verifying rather than trust the payload alone.

## Zero-day retention

Linq offers a mode in which message content is never written to its database. Its definition: "Zero-day retention means message content is retained for zero days — it is never persisted past the moment it's needed". Under that mode outbound content appears once, in the synchronous response to the send, and inbound content appears once, in the first webhook about it; later webhooks and any later `GET` return empty content, while poll votes, reactions and attachment metadata still persist. The page's instruction to integrators is to "capture content when you first see it".

## Plans and prices

Linq publishes no price. Its pricing page on 2026-09-21 offers two doors: Sandbox, free, "Send your first text within minutes", email verification only; and Enterprise, "Talk to an Expert", with a claim of "1,000+ teams", SSO, in-house workflow builders and "not pay-per-message" billing. Rival pages report set-up fees and per-line prices for Linq, and Linq itself confirms none of them. Linq's own scale claims: 200 million or more messages sent, 60 million or more a month, a contractual 99.95% uptime commitment, and median latency under 120 ms.

## Compliance as Linq states it

Linq describes itself as "the only SOC 2 Type II iMessage API" and publishes a trust center listing 70 monitored controls, audit and penetration-test reports on request, and its subprocessors. Message content is described as encrypted and inaccessible to Linq. Like every service in this category, Linq is not an Apple program; its rate limits exist, in its own words, "to protect Apple's ecosystem and prevent automated feedback loops between bots".

## Developer packaging

SDKs for TypeScript, Python and Go; a command-line tool; a plugin for Claude Code and Cursor that gives the agent a `search_docs` tool and an `execute` tool against the account; a Model Context Protocol package, `@linqapp/sdk-mcp`, that lets Claude send and receive iMessages, react, edit, and send files; an `llms.txt` index and a 2.4 MB `llms-full.txt`; and a Vercel Chat SDK adapter. Idempotency is a body field, `idempotency_key`, rather than a header.

## Sources

1. Linq llms.txt — https://linqapp.com/llms.txt
2. Linq Rate Limits — https://docs.linqapp.com/channel/imessage/guides/platform/rate-limits/
3. Linq Zero-Day Retention — https://docs.linqapp.com/channel/imessage/guides/platform/zero-day-retention/
4. Linq AI context page — https://linqapp.com/s/ai-instructions.md
5. Linq pricing — https://linqapp.com/s/pricing
6. Linq vs Blooio (Linq's page) — https://linqapp.com/s/linq-vs-blooio


---

# Sendblue: an iMessage API on Mac minis and iPhones since 2020, with its endpoints, limits and prices

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

Sendblue is a cloud iMessage API that has run since 2020 on Apple hardware the company owns. Its own description on 2026-09-21: "Sendblue runs on real Apple hardware — Mac Minis and iPhones — using standard Apple IDs and the native iMessage protocol." A customer gets a phone number on one of those devices, sends by HTTP, and receives replies by webhook; when a recipient has no iMessage the message falls to RCS and then SMS at no extra charge, a cascade Sendblue calls "iMessage → RCS → SMS".

Two terms recur. A **line** is one phone number provisioned on Sendblue's platform. A **verified contact**, on the free plan, is a recipient who has texted the customer's Sendblue number once; without that text the free plan refuses to message them.

## Authentication and base URL

Every request carries two headers, `sb-api-key-id` and `sb-api-secret-key`, against `https://api.sendblue.com` (the older host `api.sendblue.co` still answers). Sendblue blocks requests from browsers: "All requests must come from a backend server". Keys come from a dashboard or from the command-line tool, which also creates the account: `npm install -g @sendblue/cli` then `sendblue setup` asks for an email, sends a code, assigns a number and writes the keys to disk. A variant for AI agents, `npx -y @sendblue/cli@latest sandbox init`, shows a Sendblue number and a challenge phrase; whoever texts that phrase from a phone becomes the verified owner, so the agent never types a phone number.

## The endpoints

Sendblue's core surface, from its own index on 2026-09-21: `POST /api/send-message` (one recipient; fields `number`, `from_number`, `content`, `media_url`, `status_callback`, `send_style`), `POST /api/send-group-message`, `POST /api/send-typing-indicator`, `POST /api/send-reaction`, `POST /api/mark-read`, `POST /api/send-carousel` (2 to 20 images), `GET /api/evaluate-service` (does this number take iMessage), `POST /api/upload-file` and `POST /api/upload-media-object`, `GET /api/v2/messages`, full contact CRUD at `/api/v2/contacts` with opt-out and block, webhook CRUD at `/api/account/webhooks`, `GET /api/lines`, `POST /accounts/lines/add-line`, and `POST /facetime/start-call`. Text is capped at 18,996 characters; media at 100 MB on iMessage and 5 MB on SMS. `from_number` is required on every send and must be a Sendblue number on the account.

Statuses run REGISTERED, PENDING, QUEUED, ACCEPTED, SENT, DELIVERED, with DECLINED and ERROR as terminal failures. Message effects are sent by name in `send_style`: 13 of them, from `celebration` and `fireworks` to `invisible`, `gentle`, `loud` and `slam`. A `.caf` audio file renders as an inline voice note; a `.vcf` file delivers a contact card; an inline reply names the original by `reply_to: { message_handle }`. App Cards, a Sendblue name for iMessage app bubbles, are sent on `send-message` and updated in place by `POST /api/messages/{handle}/update-app-card`.

## Webhooks

Seven webhook types exist: `receive`, `outbound`, `typing_indicator`, `call_log`, `line_blocked`, `line_assigned` and `contact_created`. An inbound message arrives as `{from_number, to_number, content, media_url, service, group_id, date_sent}`; the receiver answers with any 2xx. Media URLs expire after 30 days. Webhooks are signed with a secret and must be served over HTTPS. `call_log` fires only for outbound calls placed from the dashboard.

## Limits

Sendblue's published limits on 2026-09-21: 1 message per second per dedicated number; the AI Agent plan allows 1,000 inbound contacts per day per line on a rolling 24 hours and 200 follow-ups per day per line; the Blue Ocean outbound plan allows 50 new outbound contacts per day per line, 15 per hour, and 5 messages to a contact who has not replied; the send queue holds 1,500 messages and returns 429 beyond that; iMessage detection is limited to 30 checks an hour and 100 a day per line; the contacts API to 100 requests per 10 seconds. Opt-out words (stop, unsubscribe, cancel, opt out, revoke, end, quit) are detected on every plan.

## Plans and prices

From sendblue.com/pricing on 2026-09-21: Free at $0, a shared line for prototyping with no outbound to unverified contacts and no webhooks; AI Agent at $100 per dedicated line per month, "inbound-first" with 1,000 inbound contacts a day, webhooks, media, typing and reactions, unable to start a conversation with a contact who has not texted first; Blue Ocean and Enterprise at custom, volume-based prices for full outbound, multiple lines, SOC 2 and HIPAA terms and an account manager. No per-message fee, no A2P registration, no carrier surcharge, and international messaging included; all lines carry US area codes.

## Beyond messaging

Two products sit next to the messaging API. FaceTime Audio calls start from `POST /facetime/start-call`, which returns Agora WebRTC credentials that the customer's own client joins; ordinary phone calls route through the customer's Twilio account with a verified caller id. Agent sandboxes are "isolated cloud Linux machines controlled over the Sendblue API": `POST /v3/sandboxes` creates one, `/exec` runs a command, `/files` reads and writes, and a fresh free account receives $100 of sandbox compute after phone verification; a sandbox sleeps after 10 idle minutes and resets its filesystem on wake.

Developer packaging: `npm install sendblue` and `pip install sendblue` SDKs; a local Model Context Protocol server, `npx -y sendblue-api-mcp@latest`, with 18 tools; a Vercel Chat SDK adapter; connectors for GoHighLevel, Close, HubSpot, Salesforce, Follow Up Boss, Monday, Zapier, Make and Slack; and a Chrome extension for click-to-text from any web page.

## Compliance as Sendblue states it

Sendblue's docs list "SOC 2 Type 2, HIPAA (dedicated instance required), TCPA compliant", TLS everywhere, HTTPS required for webhooks, and webhook signing secrets. Its own count of scale on the home page on 2026-09-21: "Installed 35,214+ times to generate over $2.1B+ revenue", a figure stated without a window or method. The service is not an Apple program; Sendblue's argument for legitimacy is that messages "go through the same system any normal iMessage user would use", and the same fact means an Apple block on a line ends that line.

## Sources

1. Sendblue API quickstart for AI assistants — https://sendblue.com/llms.txt
2. Sendblue docs index for machine readers — https://docs.sendblue.com/llms.txt
3. Sendblue pricing — https://sendblue.com/pricing
4. Sendblue rate limits section — https://sendblue.com/llms.txt
5. Sendblue home page — https://sendblue.com


---

# myCRMSIM: a bridge from a customer's own SIM and Apple device into a CRM for flat-rate SMS, iMessage and WhatsApp

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

myCRMSIM is a service that connects a customer's own SIM card and Apple device to a CRM so the CRM can send SMS, iMessage, WhatsApp and RCS at a flat monthly price. Its own description on 2026-09-21: "myCRMSIM connects your SIM card to your CRM for unlimited SMS, iMessage, WhatsApp, and RCS messaging at one flat monthly cost — no A2P registration, no per-message fees." That sentence contains the whole model. The other iMessage services in this category own the phones; myCRMSIM does not. The customer supplies the phone, the SIM and the carrier plan, and myCRMSIM supplies the bridge into the CRM.

Two terms carry what follows. **A2P registration** is the US carrier process (10DLC) that a business must complete before sending application-originated SMS through a carrier API; myCRMSIM's pitch is that a personal SIM in a real handset needs none of it. A **device** is one phone or Mac the customer connects; the site's footer states "Scales to 1,000s of Devices".

## What the site says it does

The home page, rendered on 2026-09-21, opens with "Connect your SIM card directly to your CRM and send unlimited SMS, iMessage & WhatsApp messages — without A2P registration or usage-based charges." Four badges follow: No A2P Registration, Fixed Cost, Unlimited SMS, AWS Secured. Channel pages exist for SMS, iMessage, WhatsApp and RCS. The iMessage page's own summary: "Send blue-bubble iMessages from your CRM. Native iOS delivery, unlimited messages, flat monthly cost." The site names HighLevel, HubSpot, Salesforce, Zoho, Make and Zapier as integrations, claims "Powering 10,000+ businesses worldwide", and lists a demo environment at demo.mycrmsim.com and an app at app.mycrmsim.com.

Security statements on the footer: hosted on AWS, AWS KMS-encrypted keys, TLS encryption. Two legal entities are named, myCRMSIM Technologies LLC with a Wyoming registered agent, and myCRMSIM Limited in Hong Kong.

## What the site does not say

myCRMSIM's pages are rendered by JavaScript in the browser, and the pricing and features routes returned the home page's content when fetched on 2026-09-21, so no price, plan limit, or API reference could be read from a primary source that day. No REST endpoint, webhook catalogue, rate limit, or per-day contact guidance appears on the public site; the product is operated from inside the CRM and the myCRMSIM app rather than by a developer API. No compliance certification is asserted.

## What the model implies

Because the iMessage identity is the customer's own Apple ID on the customer's own device, three consequences follow from the design rather than from any claim on the site. Reach is bounded by devices: one number needs one handset or one Mac session. Reputation risk sits with the customer's own Apple ID, so an Apple block on that identity is the customer's to recover. And uptime is the uptime of a phone the customer keeps powered and connected. The same design is the reason for the two things myCRMSIM promises: no carrier registration, because the messages originate from a consumer line, and no per-message charge, because the carrier plan is the customer's own.

## Sources

1. myCRMSIM home page description — https://mycrmsim.com/
2. myCRMSIM home page, rendered — https://mycrmsim.com/
3. myCRMSIM iMessage page — https://mycrmsim.com/imessage


---

# 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