WhatsApp for Developers in 2026: Features, API Updates & News

The 2026 lay of the land

If you build on WhatsApp, the platform you targeted two years ago is not the one you are shipping against today. The biggest structural change is finished rather than pending: the WhatsApp Business On-Premises API was fully sunset on October 23, 2025, leaving Meta's Cloud API as the single supported official path. Around that, pricing flipped from conversation-based to per-message billing, the old messaging-limit ladder is being dismantled, coexistence let one number run the Business app and Cloud API together, and the unofficial library ecosystem (Baileys and friends) continued its own parallel evolution toward a v7 release.

This roundup pulls those threads together for developers, with each claim grounded in primary Meta documentation and the relevant project repositories. Where numbers are volatile, such as exact per-message rates, we point you at the source of truth rather than freezing a figure that will be wrong by next quarter. The goal is a practical mental model of what is real, what is rolling out, and what is still unofficial and risky.

On-Premises is dead: Cloud API is the only official path

The On-Premises API, where you self-hosted the WhatsApp Business client containers, is gone. Meta stopped accepting new On-Premises sign-ups after July 1, 2024, shipped all new feature work to Cloud-only beginning early 2024, and the final client version expired on October 23, 2025. After that date, messages to or from numbers still registered on On-Premises simply stop being delivered. There is no extension and no parallel maintenance track.

The official replacement is the Meta-hosted Cloud API, launched in 2022. For developers, the practical implications are concrete: you no longer run or scale your own messaging infrastructure, webhooks and the Graph API endpoints replace the local REST client, and feature parity now flows to Cloud first. On throughput, the Cloud API default is 80 messages per second (MPS) per business phone number, scaling automatically to 1,000 MPS for eligible numbers based on quality rating and status, so do not assume the 1,000 MPS ceiling out of the box. The more important point is architectural: if any tutorial, SDK, or internal doc you rely on still references On-Premises containers, treat it as expired.

Pricing: from per-conversation to per-message

The 2022 model billed a single fee per 24-hour conversation window. That model is now deprecated. On July 1, 2025, Meta switched to per-message pricing for template messages across all categories at once: each delivered template is billed individually as marketing, utility, or authentication. There was no staged 'utility first, marketing later' rollout of per-message billing, both flipped on the same date when conversation-based pricing was retired.

April 1, 2025 brought a separate, earlier set of changes that are easy to conflate with the July transition but are mechanically different. From that date: (a) utility templates sent inside an open 24-hour customer service window became free, (b) Meta lowered authentication-international rates for Egypt, Nigeria, Pakistan, and South Africa, and (c) Meta banned sending marketing templates to U.S. (+1) numbers. So utility messages are not simply 'billed per-message since April 2025', under the July 1, 2025 model a utility template is free when sent in an open service window and billed per-message only when sent outside that window.

The other half of the picture is genuinely good for developers building support tooling: service conversations became free and unlimited on November 1, 2024 (previously capped at 1,000 free per month). In practice, any reply you send inside the 24-hour customer service window, opened when a user messages you, is free and needs no template. You pay for business-initiated templates sent outside that window. Conversations started from Click-to-WhatsApp ads open a free entry-point window (historically 72 hours), check Meta's current terms before relying on a specific duration.

Rate adjustments continue on a rolling basis (for example, market-specific changes took effect January 1, 2026). Because exact per-message dollar figures vary by market and country calling code and change over time, do not hardcode them in budgeting logic; pull the current numbers from Meta's pricing page and revalidate periodically.

Messaging limits and the new identity model

Meta is retiring the familiar 1K / 10K tier ladder. Qualified and verified businesses move toward a flat 100K daily messaging limit, with rollout reported beginning with select partners in Q1 2026 and broader removal of the old tiers through Q2 2026. Treat this as in progress rather than universally live; your account's status depends on Business Verification and messaging quality.

More consequential long-term is a shift in how you identify customers. WhatsApp is introducing a business-scoped user ID (BSUID), a per-business identifier that is unique to each business, so the same person has a different BSUID with each company they message. In parallel, WhatsApp usernames are rolling out (starting in test countries around mid-2026) to improve phone-number privacy, meaning a user's raw phone number may not always be visible to a business.

For developers, the takeaway is to stop treating the phone number as your permanent primary key for a contact. Design your data model so an opaque, business-scoped identifier can become the join key, and keep phone-number handling defensible from a privacy standpoint. These pieces are announced and partially rolling out, so build for the direction of travel rather than assuming today's behavior is permanent.

Coexistence: one number, Business app plus Cloud API

Coexistence is one of the most-asked 2026 developer questions, so it deserves its own treatment. It lets a single phone number run the WhatsApp Business app and the Cloud API at the same time, without migrating the number off the app or losing its chat history. Messages sent in the app show up in the API inbox and vice versa, which means a small team can keep replying from the phone while automation and integrations run through Cloud.

On timing, be precise: Meta rolled coexistence out through 2025 (beta early in the year, an Embedded Signup onboarding path mid-2025, and broad global availability by late 2025), reaching general partner availability by early 2026, with additional supported countries added in 2026. It was not a January 2026 launch, that is just when some BSPs surfaced it to their customers.

The practical caveats: each Business app account maps to one number under coexistence, and once you onboard, Cloud-API-initiated and business-initiated messages follow the standard pricing model described above (app-side personal chatting stays free). If you are choosing between a clean Cloud-API-only setup and coexistence, coexistence is the lower-friction path for businesses that still want the app's manual inbox alongside programmatic messaging.

Multi-device architecture and end-to-end encryption

WhatsApp's multi-device design, generally available after its 2021 beta, lets a phone and up to several companion devices each operate with their own identity and encryption keys, rather than the phone acting as a relay. The server maintains a per-account device-list mapping, and a sender uses a client-fanout model: it encrypts and sends the message once per recipient device over pairwise Signal-protocol sessions. A practical security consequence is that compromising one device's keys does not expose the others.

On the cryptography side, WhatsApp has been hardening end-to-end encryption with post-quantum key exchange (PQXDH) to protect against future 'harvest now, decrypt later' attacks. If you cite specifics, verify them against the current WhatsApp Security Whitepaper, since the cryptographic stack is updated over time.

Why this matters even if you only use the Cloud API: the multi-device model is what makes companion sessions, including the Web protocol that unofficial libraries ride on, possible. It also shapes message ordering, session setup, and the failure modes you will observe when a device falls out of the device list.

Baileys and the unofficial library scene: get the names right

Baileys is a community, reverse-engineered, WebSocket TypeScript library for the WhatsApp Web protocol. It is not the official Cloud API and is explicitly not affiliated with or endorsed by WhatsApp or Meta (its README says so). It is MIT-licensed and maintained by Rajeh Taher under the WhiskeySockets GitHub org, after the original repository by Adhiraj Singh was taken down by its creator and the project was adopted under WhiskeySockets.

The naming is a common source of error. The long-standing scoped npm package is @whiskeysockets/baileys, and it predates v7. With the v7 line, the project also publishes the unscoped baileys package, and both currently resolve to the same v7 release-candidate stream. So the tidy 'renamed to @whiskeysockets' story is incomplete: v7 reintroduced the bare baileys name alongside the scoped one.

# Scoped package (established, predates v7)
npm install @whiskeysockets/baileys

# Unscoped package (reintroduced in the v7 line)
npm install baileys

# v7 is still a release candidate as of 2026 — pin explicitly
npm install @whiskeysockets/[email protected]

Status check: v7 is the largest release since the WhiskeySockets fork and ships breaking changes (there is an official v7 migration guide on baileys.wiki). As of this writing it is still pre-stable, running as a 7.0.0-rc.x series into 2026 (confirmed at rc.13) after a roughly five-month gap with no release. Notable v7 work includes moving dependencies from git to npm for transparency, caching wins in binary-node lookups, and groundwork to replace the libsignal dependency. The library remains popular, with hundreds of thousands of weekly npm downloads, and supports Node.js, Bun, and Deno.

Communities, Channels, Flows and calling: the official vs unofficial split

A precise distinction matters here: the official Cloud API does not offer full Communities or Channels management. That kind of automation comes only from unofficial Web-protocol libraries, which carry the ToS and ban risk described above. So if your roadmap depends on programmatically managing Channels or Communities, understand that you are choosing the unofficial path with its tradeoffs, not a sanctioned Meta feature.

Several other 2025-2026 platform updates are worth tracking, framed honestly as shipped, announced, or in progress. Flows gained support on WhatsApp Web from late 2025, broadening where interactive forms render. Business calling capabilities are expanding, with updated calling pricing slated to take effect July 1, 2026 across multiple currencies, so if voice is on your roadmap, budget for it as a distinct billed feature rather than assuming it rides on messaging rates.

Many production teams end up with a hybrid mental model: the Cloud API for compliant outbound messaging, and a lightweight, read-only verification layer for enrichment that does not touch messaging at all. Disclosure: this site offers such a product, a focused profile-lookup API, which is why we mention it here, it lets you confirm whether a number is on WhatsApp and pull public profile data without running a session that could get a number banned. Evaluate it against any alternative on its own merits.

What to do with all this

• Audit any code or docs referencing On-Premises; that path stopped delivering messages on October 23, 2025. Standardize on Cloud API.
• Move budgeting and rate-limit logic off the old conversation model. Bill per template since July 1, 2025, treat service-window replies (and in-window utility templates since April 1, 2025) as free, and pull live rates from Meta rather than hardcoding.
• Plan for throughput: assume the 80 MPS default and design for graceful scaling rather than expecting 1,000 MPS immediately.
• Stop assuming the phone number is your permanent contact key. Prepare for BSUID and usernames, and keep phone-number handling privacy-defensible.
• If you want the Business app and Cloud API on one number, evaluate coexistence (generally available to partners by early 2026) instead of a disruptive migration.
• If you use Baileys, pin a specific 7.0.0-rc version, read the v7 migration guide, and decide consciously whether @whiskeysockets/baileys or baileys is right for your install.
• Keep unofficial messaging automation out of anything where a banned number would hurt. Use the Cloud API for production sends.

The through-line for 2026 is consolidation around the official platform for messaging, paired with a still-vibrant unofficial ecosystem for everything Meta does not expose. Knowing exactly which side of that line a given feature lives on is the single most useful thing you can carry into your next WhatsApp integration.

Frequently asked questions