Synthesis — Business Messaging

The evolving thesis. This spoke was spun out of the hub's messaging-apis _inbox cluster on 2026-07-01, when three WhatsApp-platform sources (a client SDK, the platform reference, and the partner-program docs) cohered and no existing spoke owned "a business-messaging platform and its API." It owns the messaging-transport layer — the platform, its API, and the SDKs and partners that sit on it — beneath the chat bots that other spokes cover.

Current thesis

The interesting object here is not the bot but the pipe it rides on. A WhatsApp assistant like whatsapp-chatgpt-bot is, from this spoke's angle, just a consumer of a large and specific delivery system. Three layers recur across the founding sources:

1. The platform — whatsapp-business-platform. Meta's WhatsApp Business Platform, delivered through the Cloud API, is the substrate: every business integration is anchored to a WhatsApp Business Account (WABA), sends through verified business phone numbers, and receives via webhooks. It is a permissioned, metered channel, not an open socket — which shapes everything above it.

2. The gate — message-template and the conversation model. WhatsApp does not let a business message anyone at will. Business-initiated contact must use pre-approved message templates sorted into categories (marketing / utility / authentication / service); free-form replies are only allowed inside a customer-initiated conversation window. This template/approval gate is the defining constraint of the channel and the main thing an integrator designs around — it is why WhatsApp integration is hard enough to justify SDKs and intermediaries in the first place.

3. The intermediaries — SDKs and BSPs. Two ways to bridge the gap between an application and the raw API. A client SDK like wapi-go hides payload construction so a developer can call the API directly. A Business Solution Provider / Solution Partner (business-solution-provider) is the heavier path: an approved intermediary offering embedded signup, a shared credit line, and managed onboarding, so a business need not integrate Meta directly at all. wassenger is a live example of the BSP-class vendor — the same role the agentic bot leaned on for connectivity.

The through-line: WhatsApp's friction is productive. The metering, template approval, and partner tiers are exactly what create a market for SDKs, BSPs, and turnkey bots — the layers this spoke and its agentic-tooling neighbor split between them.

The multi-channel turn

A research pass added two more operators — rcs-business-messaging (Google) and apple-messages-for-business (Apple) — alongside WhatsApp's now-documented billing model (per-message-pricing). Three channels is enough to separate what is WhatsApp from what is business messaging, and the answer is that almost none of the shape was WhatsApp-specific.

Every channel builds the same three gates, and differs only in where it puts them.

Read across the rows, the through-line sharpens: the channels sell reach into a space the user did not open for marketing, so each one polices identity, content, and the intermediary — and the policing is the product. WhatsApp enforces continuously (every template), Apple enforces up front (the experience review), RCS enforces at launch and then hands part of the veto to carriers.

Two channels have since broken the symmetry, from opposite ends (2026-09-02 and 2026-09-04). Telegram builds none of the three gates: BotFather issues a token and you send. LINE builds an identity gate and then declines to make it a condition of sending — an unverified account can message anyone who added it, and simply cannot be found in LINE's in-app search. So five channels give three designs: gate the sending (WhatsApp, RCS, Apple), gate nothing (Telegram), or gate the discovery and sell the key (LINE, where verification also unlocks friend-add ads and invoice billing). The gates are a policy choice by the operator, and where they exist they mark a channel that intends to charge for reach.

Two findings worth keeping separate from that symmetry:

• The intermediary is the real constant. business-solution-provider now documents the role across all three, and Apple's version is compulsory. A brand's relationship with these channels is usually mediated by a partner, which is exactly why sender-verification verifies two things: the brand's identity, and the partner's right to act for it rcs-brand-verification.
• Billing is policy. per-message-pricing makes customer-initiated conversation free and business-initiated marketing always billable, and routes volume discounts to the categories WhatsApp considers legitimate whatsapp-pricing-docs. The customer-service-window is where permission and price become the same mechanism.

Verdict on the founding question: the durable subject is business messaging across channels, not the WhatsApp Business Platform. The domain line in CLAUDE.md has been updated accordingly. WhatsApp remains the deepest corner by source count, and the comparison is still thin — one to two sources per non-WhatsApp channel.

The East Asian super-apps (2026-09-22) move the gate from identity to content. WeChat (wechat-official-account-messaging) and Kakao (kakao-bizmessage) are restrictive, as they are usually described, but neither makes sender identity the main control. WeChat limits what a business may push (service notices only, no marketing) and how much it may reply (five messages in 48 hours after a user writes), and it spends user consent one notification at a time. Kakao lets an inspected transactional template reach any phone number and keeps advertising for users who opted in. Across the eight channels now held, the gate falls in three places: who may send (WhatsApp, Apple, RCS, the US carriers), who may be found (LINE), and what may be sent to whom (WeChat, Kakao). Telegram gates nothing.

The unofficial path

chatery-whatsapp is the first source here that does not come through the front door. It is an Express server over baileys, a library that speaks the WhatsApp Web protocol directly: it authenticates by QR-pairing an ordinary account as a linked device, and from there sends whatever it likes to whoever it likes.

Every gate in the table above is absent. No business verification, no WABA, no message-template approval, no BSP, nothing under per-message-pricing. The features it advertises are precisely the ones the official platform makes expensive: many accounts on one deployment, and queued bulk sending.

This does not refute "the policing is the product" — it prices it. The tolls are not a technical necessity, since the same users are reachable without paying any of them. What the official path sells is permission and durability: a sanctioned integration that Meta will not ban and that does not break when the protocol shifts. Baileys moves enforcement from approval-before-sending to account-bans-after, and moves cost from per message to reliability and risk. Which is the better deal depends entirely on whether the sender wanted consent-shaped reach or volume.

So the honest form of the thesis is narrower than the founding one: the gates make the channel legible and safe to build a business on, and they do not control access to WhatsApp's users. That distinction was invisible while every source described the sanctioned path.

Reach for the unofficial path is not evidenced here. baileys has 11.3k stars and chatery-whatsapp 214, which says a market exists and nothing about its size against the official one. No ban-rate, deliverability, or enforcement data is in the corpus.

Re-verified 2026-10-07: the instability is now two-sided. baileys shipped a breaking 7.0.0 and is mid-migration to a new documentation site. The unofficial path was already named as riskier because the protocol can change under it; a breaking change in the library itself, independent of WhatsApp, is a second source of the same risk. "Pay in reliability and risk rather than per message" now has two things that can break, not one.

Billing-is-policy is a WhatsApp property, not a channel property (added 2026-08-22)

a2p-10dlc is the first non-Meta meter this spoke holds, and it disagrees with the spine.

The thesis has said that on WhatsApp billing is a policy instrument: per-message-pricing charges by message-template category, makes customer-initiated conversation free inside the customer-service-window, discounts by volume tier, and lets the categories Meta considers legitimate cost less than the one it tolerates. Price is used to shape what gets sent.

US carrier SMS does none of that. Every segment costs the same — $0.0083 plus a $0.0035–$0.005 carrier surcharge, read from twilio's list price on 2026-08-22 — whatever the message says, whoever started the conversation, and however much you send. Volume does not buy a discount; it buys a ceiling, and the ceiling is set by which brand tier you registered under (~3,000 / ~6,000 / unlimited segments a day).

So both channels are gated, and the gate does a different job in each. Meta prices the traffic it wants and taxes the traffic it tolerates. The US carriers decide who may send at all, through Brand and Campaign registration, and then charge a flat rate for the pipe. The open question about pricing beyond WhatsApp assumed the answer would be another billing model; the answer is that the policy moved out of the price and into the registration.

The registration is the familiar half. Brand registration is sender-verification with a different name. Campaign registration — a declared purpose plus opt-in, opt-out and help handling, approved before traffic flows — is what message-template approval does, one level up: 10DLC approves the use case where WhatsApp approves the text. Two ecosystems that share no technology arrived at the same shape, which strengthens the spine's claim that permissioned business messaging is the norm rather than a Meta peculiarity.

And there is a third party in the price. Verizon charges more for an inbound message than an outbound one; AT&T and T-Mobile charge different amounts for the same message. WhatsApp has one counterparty setting one price, so the destination never enters except as a country code. Here the destination network prices your traffic after you have paid your provider — the structure the RCS billing question was guessing at, observed on the channel next door.

One thing this does not settle: the enforcement claim. The docs say unregistered traffic is surcharged rather than blocked, and that registering brings "lower message filtering and higher messaging throughput" — a statement about carrier behaviour, published by a reseller, with no filtering rate on either side of it. That is the same evidence gap as open question 3 about the unofficial WhatsApp channel, and it is unclosed on both channels now.

Open questions

• Pricing beyond WhatsApp. No billing model is sourced for RCS or Apple. Partly answered 2026-08-22 by a2p-10dlc — not RCS or Apple, but a second channel with a published meter, and it falsified the general form of the claim: US carrier SMS is a flat rate with a registration gate, so "billing is policy" describes WhatsApp rather than business messaging (see the section above). Still open for RCS and Apple specifically, where carriers appear to hold part of the billing and nothing is sourced.
• Where exactly is the agentic-tooling seam? A GPT-4o WhatsApp bot is an agent product (there); the WhatsApp transport is here. But a BSP that ships an AI auto-responder blurs the line. Rule of thumb so far: if the model/agent loop is the point, it's agentic-tooling; if the channel/API/partner mechanics are the point, it's here. Tested 2026-08-05 and it held, though on an easy case: chatery-whatsapp has no model in it at all, so it was transport by construction. The genuinely hard case — a product where the agent and the transport are equally the point — has not arrived.
• How large is the unofficial channel? New with baileys and unanswerable from this corpus. It decides whether the gates shape the market or merely shape the documented market, and it needs a source neither Meta nor a library maintainer would write: enforcement data, ban rates, or a survey of how businesses actually reach WhatsApp users.
• Pricing & template-category volatility. WhatsApp has repeatedly repriced conversations and reshuffled template categories. Any pricing/tier claim is a dated snapshot — flag, don't rely.

Growth edges

Ranked; each names the kind of source that would close it (see ../QUALITY.md → Growth edges).

1. Pricing beyond WhatsApp. No billing model is sourced for RCS (carriers appear to hold part of it) or Apple, so "billing is policy" rests on one channel. — needs: carrier or Apple first-party billing documentation (T3 acceptable — it is a first-party fact). Half closed 2026-09-04 by line-official-account-plans (T1, LY Corporation's own rate card), which supplies a third billing model without touching either channel the edge names: a monthly subscription with a message quota (¥0/200, ¥5,000/5,000, ¥15,000/30,000; overage only on the top plan, ¥3→¥2.6). Nothing is priced by message category. So "billing is policy" is now measured against two counterexamples rather than one, and is firmly a WhatsApp property. — still needs what it always needed: RCS carrier billing and Apple's model.
2. How large the unofficial channel is. baileys raised it and this corpus cannot answer it; it decides whether the gates shape the market or only the documented market. — needs: enforcement data, ban rates, or a survey of how businesses actually reach users.
3. The hard agentic-tooling boundary case. The rule has only been tested on an easy one — a product with no model in it. — needs: a source where the agent loop and the transport are equally the point.

Coverage edges (added 2026-08-08, at the curator's request for a wider backlog). These widen what the spoke covers instead of answering an open question above; one ordinary solid source closes any.

4. SMS, the channel everything else is measured against. Closed 2026-08-22 by a2p-10dlc (T3, twilio's compliance docs plus its published US rate card) — CPaaS documentation plus current per-message rates, which is exactly what the edge asked for. It did more than supply a baseline: it contradicted the spine's billing-is-policy claim, which now belongs to WhatsApp rather than to the domain. — successor, edge 4a: the enforcement figure behind it. The only published account of what registration buys ("lower message filtering, higher throughput") is a reseller's, with no filtering rate on either side. — needs: carrier or regulator data on delivery or filtering rates for registered against unregistered A2P traffic.
5. The layer between brand and channel. business-solution-provider describes the role and no vendor is written up — Twilio, Infobip, MessageBird. One-third started 2026-08-22: twilio is paged, but only as far as the 10DLC ingest established — the wider platform is unsourced, and Infobip and MessageBird are absent. — still needs: first-party platform docs and pricing for a second and third vendor, and enough of any one of them to compare the CPaaS role against the BSP role rather than assert they are the same shape.
6. The markets where a different app is the default. A quarter closed 2026-09-02 by telegram-bot-api (T1, Telegram's own docs, Bot API 10.3) — recorded here on 2026-09-03, because the page was written and the edge was left saying "needs", which is the third instance of that failure this week. The result is sharper than the edge expected: Telegram has no gate at all. Message BotFather, receive a token, send. No brand registration, no authorization of an intermediary, no review of the conversation — so the identity/content/intermediary pattern this spoke calls universal turns out to be a policy choice by the operator, not a requirement of running a channel. Noted on sender-verification beside the three-channel table. Half closed 2026-09-04 by line-messaging-api + line-official-account-plans (both T1, first-party). The guess in the sentence below was wrong, and usefully so: LINE is not the restrictive pole. Sending is ungated — open an account, push messages, no review — but the account is issued unverified and an unverified account cannot be found in LINE's in-app search. Verification is applied for (5–10 business days, official business name, unchangeable after applying) and returns the green badge, searchability, friend-add ads and invoice billing. The gate is real and entirely optional; what it sells is discovery, not permission. Recorded on sender-verification as a third design beside blocking and absence. — still needs: WeChat and KakaoTalk, one page each. The spectrum now has three points, and the two remaining super-apps are the ones actually described as restrictive; nothing here yet tests that description. Closed 2026-09-22 by wechat-official-account-messaging and kakao-bizmessage (both T1, first-party docs). The description holds, with a correction to what is restricted: both gate content and consent, not identity. WeChat caps replies (5 in 48 h), bans marketing in push templates and counts consent per notice; Kakao lets inspected transactional templates reach any number and confines ads to friends or consented users. Recorded on sender-verification. Not yet read: who may register a WeChat account, and either platform's prices.
7. Consent and the law behind it. Templates, verification and pricing are covered; opt-in rules (TCPA, GDPR marketing consent) are the constraint that makes template approval exist. — needs: the statute or a regulator's guidance.

Contradictions / tensions

The first real contradiction arrived 2026-08-05. The founding thesis calls WhatsApp "a permissioned, metered channel, not an open socket." chatery-whatsapp reaches the same users through something very close to an open socket, using baileys. Both claims stand, because they describe different doors: Meta's documentation (whatsapp-business-platform-docs) describes the one Meta built and will support, and it is accurate about that door and silent about the other. Recorded rather than resolved — the platform pages keep the permissioned description, and the qualifier is now on whatsapp-business-platform.

Two further tensions worth naming:

• "Friction is productive" cuts both ways. The founding thesis reads the gates as market-making: they create the SDK/BSP layer. The three-channel view suggests a plainer reading — the gates are rent collection on access to an attention-scarce surface, and the intermediary layer is a cost of that, not a happy side effect. Both readings fit the evidence; neither source argues either.
• Vendor claims outrunning documentation. Capabilities widely attributed to RCS (carousels, typing indicators, specific carrier reach) are not in Google's own docs rcs-business-messaging-docs, and "server-to-server REST" for Apple is a vendor gloss the primary page does not state apple-messages-for-business-docs. Where this wiki's channel pages are quieter than the marketing, that is deliberate.

Cross-spoke adjacency

• ../agentic-tooling-wiki — the closest neighbor. It owns LLM bots that ride this platform (whatsapp-chatgpt-bot) and the WhatsApp API vendor wassenger (created there as that bot's maintainer). Split rule: agent/model = there, messaging platform/transport = here. Cross-link, never duplicate.
• ../dev-tooling-wiki — declined as a home for wapi-go (the Ky precedent: an application-level API client is a runtime dependency, not build/ship infrastructure). The messaging SDK lives here by subject (WhatsApp), not as generic dev tooling.
• ../search-marketing-wiki — faint seam: WhatsApp marketing templates are a performance-marketing channel. If WhatsApp-as-marketing-channel sources arrive, cross-link the campaign/measurement angle there and keep the platform mechanics here.

Index — Business Messaging Wiki

Catalog of every page, grouped by schema.org @type. Spine: synthesis (thesis), log.md (history), this file (catalog). Some wiki-links resolve to neighbor nodes in ../agentic-tooling-wiki (intentional cross-wiki links). Three channels as of 2026-07-30 — WhatsApp is the deepest corner; RCS and Apple are newly sourced. Rates and tiers are dated snapshots, and where a channel page is quieter than the vendor marketing, that is deliberate.

WebAPI / SoftwareApplication (platforms & SDKs)

• whatsapp-business-platform — hub node: Meta's WhatsApp Business Platform (Cloud API); permissioned, metered, template-gated, and the only one of the three with a direct-integration path · platform
• rcs-business-messaging — Google's RCS channel; the brand messages as a verified agent, and carriers hold part of the gate (Google-managed vs carrier-managed launch) · platform
• apple-messages-for-business — Apple's Messages channel; a mandatory Messaging Service Provider, an experience review before go-live, and entry points Apple controls · platform
• telegram-bot-api — Telegram's Bot API (10.3, Aug 2026): BotFather issues a token and you send — no identity, content or intermediary gate at all; long polling or webhook, updates held 24h. The permissive extreme of the spoke's gate spectrum · source · T1 · core.telegram.org
• line-messaging-api — LY Corporation's LINE Official Account API: reply and unrestricted push (no service window), 11 message types. Sending is ungated, but an account is issued unverified and an unverified account cannot be found in LINE's in-app search — the green-badge review (5–10 business days) sells discovery, ads and invoice billing rather than permission · source · T1 · developers.line.biz
• wechat-official-account-messaging — Tencent's own docs, read 2026-09-22: replies capped (5 in 48 h after a user message, 3 in 1 min after follow/scan/menu); push templates for service notices only, no marketing; subscription consent counted per notice; long-term subscriptions for public services only · source · T1
• kakao-bizmessage — Kakao i Connect Message docs, read 2026-09-22: AlimTalk (inspected transactional templates, reaches non-friends by phone number, SMS fallback) vs FriendTalk / Brand Message (ads, friends or marketing-consented users only) · source · T1
• wapi-go — WapiKit's Go SDK over the WhatsApp Business API; the direct-integration client layer · source · T2 · golang.wapikit.com
• baileys — WhiskeySockets' TS library speaking the WhatsApp Web protocol over a WebSocket; the unofficial second door — QR-paired, ungated, unmetered, against Meta's terms · library
• chatery-whatsapp — farinchan's Express.js API backend over baileys: multi-session, bulk send, webhooks, no WABA and no LLM. The spoke's first source from outside the sanctioned path · source · T1 · github.com

DefinedTerm (concepts / roles)

• whatsapp-business-account — WABA: the top-level entity owning a business's numbers, templates, settings; identity + metering attach here · concept
• message-template — the pre-approved, categorized format for business-initiated messages; since 2025 the category is also the billing unit · concept
• customer-service-window — the 24-hour reply window (72h via a free entry point); a permission rule and a price at the same time · mechanism
• per-message-pricing — WhatsApp's billing model since 1 July 2025: charged per delivered template, free inside the window, volume-tiered on utility/auth · billing model
• sender-verification — the gate all three channels share: proving the brand's identity and the intermediary's right to act for it · cross-channel pattern
• a2p-10dlc — the US carriers' registration regime for SMS from ordinary ten-digit numbers, and the baseline the rest of this wiki was being compared against without holding it. Brand + Campaign registration (identity, then declared purpose and opt-in/opt-out) gate the channel; brand type sets a daily ceiling (~3,000 / ~6,000 / unlimited segments); unregistered traffic is surcharged, not blocked. $0.0083 per outbound SMS segment plus a per-carrier surcharge of $0.0035–$0.005 — flat, whatever the message says and whoever started the conversation. The comparison is the finding: WhatsApp uses billing to shape what gets sent, the US carriers use approval to decide who may send and then meter a flat pipe · source · T3 · twilio.com
• business-solution-provider — the intermediary role across channels: BSP/Solution Partner (WhatsApp, optional), messaging partner (RCS), MSP (Apple, mandatory) · role

TechArticle (sources)

• whatsapp-business-platform-docs — Meta's first-party WABA / Cloud API reference; the canonical platform description · source · T1 · developers.facebook.com
• whatsapp-solution-partner — Meta's BSP / Solution-Partner get-started (embedded signup, credit line, role split) · source · T1 · developers.facebook.com
• whatsapp-pricing-docs — Meta's pricing reference: per-message billing since 1 July 2025, category rules, the free entry point, volume tiers, 2026 rate changes · source · T1 · developers.facebook.com
• rcs-business-messaging-docs — Google's RCS for Business landing docs: agents, APIs, Developer Console, the carrier role, two launch paths · source · T1 · developers.google.com
• rcs-brand-verification — Google's agent verification guide: the authorization email to a named brand representative, Google- vs carrier-managed approval, the verified checkmark · source · T1 · developers.google.com
• line-official-account-plans — LY Corporation's own rate card: ¥0/200 messages, ¥5,000/5,000, ¥15,000/30,000 per month, overage on the top plan only (¥3 → ¥2.6 by volume), Chat Pro ¥3,000, Premium ID ¥100/mo. Invoice payment requires verified status. Nothing is priced by message category — the corpus's third billing shape, after WhatsApp's policy pricing and A2P SMS's flat carriage · source · T1 · lycbiz.com
• apple-messages-for-business-docs — Apple's end-to-end walkthrough: the brand/MSP/Apple roles, registration, the experience review, entry points, features · source · T1 · register.apple.com

Person

• fajri-rinaldi-chan — maintainer of chatery-whatsapp

Organization

• meta — owner of WhatsApp; operator & first-party publisher of the WhatsApp Business Platform · platform owner
• apple — operator of Apple Messages for Business; the strictest of the three gatekeepers · platform owner
• ly-corporation — operator of LINE (Z Holdings + Yahoo! Japan + LINE, merged 2023; owned via A Holdings by SoftBank and Naver); the spoke's fourth channel operator and the first outside the US · platform owner
• twilio — the CPaaS behind a2p-10dlc; the brand-to-channel intermediary arrived at from the carrier side rather than the platform side, and the first vendor member of coverage edge 5 · intermediary

Synthesis

• synthesis — the evolving thesis: three channels, three gates each (identity / content / intermediary), and the policing as the product

Neighbor nodes (live in sibling wikis, linked cross-wiki)

whatsapp-chatgpt-bot · wassenger (../agentic-tooling-wiki — the GPT-4o WhatsApp bot and its WhatsApp API vendor; they ride on this platform) google (../llm-providers-wiki — operator of RCS for Business; the canonical Google node lives there)