WhatsApp On-Premises API: Sunset Dates and the Cloud Move

Maybe you inherited a repository with Docker files called coreapp and webapp. Maybe a vendor proposal promises an "on-premise WhatsApp API" for data control. Or a compliance document still describes a WhatsApp client running in your own data centre. All three point at something that no longer works.

The WhatsApp On-Premises API was the self-hosted version of the WhatsApp Business API. Meta retired it in stages, and its final version expired on October 23, 2025. Since then, the Cloud API, hosted by Meta, is the only way to use the official platform for messaging.

This post covers what the On-Premises API was, the exact sunset timeline from Meta, what migrating teams had to change, and what to do if you still find references to it. For the platform today, see the complete guide to the WhatsApp API.

What the On-Premises API was

It was the original WhatsApp Business API: software you ran on your own infrastructure, which then talked to WhatsApp's servers. Large brands and most early Business Solution Providers used it, often with the provider hosting it on the business's behalf.

From Meta's installation docs, a deployment had three parts:

• Webapp container: handled authentication and the REST API your systems called, listening on port 9090 by default.
• Coreapp container: sent messages to WhatsApp's servers and stored media on a shared volume.
• A database: MySQL 5.7 or 8.0, or PostgreSQL 11 to 13, holding messages, contacts and configuration.

It ran on Linux with Docker; Docker for Windows was not supported. Meta's recommended production machine was 250 GB of SSD, 16 GB of RAM and 4 cores. Your code authenticated by calling /v1/users/login with basic auth to get a bearer token, and you upgraded the client yourself, because each version expired.

People chose it for control. Messages sat in your own database, inside your own network, on hardware you managed. That was also its cost: you ran the servers, the database, the backups, the upgrades and the scaling.

The sunset timeline

Meta's On-Premises API sunset page lays out the retirement. With the earlier history added for context:

The last line is absolute. Per Meta, messages sent to or from business numbers still registered for the On-Premises API are not delivered. There is no extended support tier and no way to renew an expired client.

What changed for teams that migrated

The number stayed the same; almost everything around it changed. Meta's migration guide said moving a number to the Cloud API kept its display name, verification status, quality rating, templates and WhatsApp Business Account. Registering the number on the Cloud API deregistered it from the On-Premises client, and Meta recommended moving a low-volume number first to check the integration.

What did not carry over was message history. It lived in your own database, and the Cloud API has no import for it, so teams that needed it kept the old database or exported it.

The rest of the stack had to be rewritten:

In code, a send changed roughly like this. The first call is illustrative of the retired API and no longer works:

# On-Premises (retired): your own host and a login token
curl https://wa.internal.example.com:9090/v1/messages \
  -H "Authorization: Bearer $ONPREM_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"to": "919811122233", "type": "text", "text": {"body": "Your order has shipped."}}'

# Cloud API: Meta's host, a phone number ID and a system user token
curl https://graph.facebook.com/v23.0/PHONE_NUMBER_ID/messages \
  -H "Authorization: Bearer $WHATSAPP_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"messaging_product": "whatsapp", "to": "+919811122233", "type": "text", "text": {"body": "Your order has shipped."}}'

Use the current Graph API version from Meta's changelog in place of v23.0. Webhooks needed the most new code, because the Cloud API wraps every event in an entry and changes structure and expects you to answer a verification request first:

app.get("/webhook", (req, res) => {
  const mode = req.query["hub.mode"];
  const token = req.query["hub.verify_token"];
  if (mode === "subscribe" && token === process.env.VERIFY_TOKEN) {
    return res.status(200).send(req.query["hub.challenge"]);
  }
  res.sendStatus(403);
});

Some providers also warned that a few audio formats accepted on the On-Premises client were not supported on the Cloud API, so media libraries needed re-encoding. Our guides to WhatsApp API access tokens and verifying webhook signatures cover the two pieces most teams rebuilt.

Data and compliance after the move

The biggest shift was not technical. With the On-Premises API, you held the message data. With the Cloud API, Meta processes and stores it, and you hold only what your webhook handler saves.

Two things soften that. Meta's local storage setting, configured per phone number, keeps message content at rest in a chosen region; content may be processed elsewhere for up to 60 minutes first. And you can keep your own complete record by writing every inbound message and status webhook to your database, which is now your responsibility rather than a side effect of the client.

If your privacy notices, records of processing or vendor contracts still describe a self-hosted WhatsApp client, they are out of date. Meta, and any provider you use, are now part of the processing chain. This is not legal advice; our post on WhatsApp API data privacy covers the questions to take to your counsel.

If you still find On-Premises references

A year after the sunset, leftovers are common. Work through these:

1. Check every number's platform. Request platform_type on each phone number ID. A healthy number returns CLOUD_API.
2. Retire the containers and the database properly. Old message databases hold personal data; delete or archive them under your retention policy rather than leaving them on a forgotten server.
3. Replace login-token code with a system user token stored as a secret.
4. Rebuild webhook handling with signature checks and idempotent processing.
5. Question "on-premise" offers. In 2026, a vendor offering an on-premise WhatsApp API is either hosting its own software in front of the Cloud API or running an unofficial client. Neither is Meta's retired product, so ask which it is.
6. Update runbooks and compliance documents so nobody plans around a product that no longer exists.

curl "https://graph.facebook.com/v23.0/PHONE_NUMBER_ID?fields=platform_type,quality_rating,throughput" \
  -H "Authorization: Bearer $WHATSAPP_TOKEN"

If you are setting up from scratch instead, the Cloud API setup guide starts from a fresh app, and our Cloud API explainer covers how the hosted model works.

Where Tenashi fits

Teams that ran the On-Premises API usually valued two things: owning the number and owning the conversation record. Tenashi is not a self-hosted product and not a replacement for Meta's platform, but it addresses both for the conversational side of WhatsApp. You link the WhatsApp or WhatsApp Business number you already own by QR scan, the number stays on your phone, and every DM and group lands in one shared team inbox with a CRM under each chat. Messages a customer deletes on WhatsApp are kept and tagged "Deleted on WhatsApp", so the record stays complete.

Developers get an API on every paid plan, with signed webhooks your systems can log and store. The limit to be clear about: Tenashi sends are deliberately paced and it does not use the official API, so it is not a fit for OTPs or high-volume alerts that once ran on large On-Premises deployments. Plans start from $18/mo.

Read the API docs · Get started

FAQ

Is the WhatsApp On-Premises API still available?

No. Meta stopped adding features in January 2024, blocked new On-Premises registrations from July 1, 2024, and the final version expired on October 23, 2025. Since then the On-Premises API cannot send messages, and messages to or from numbers still registered on it are not delivered. The Cloud API is the replacement.

When did the WhatsApp On-Premises API stop working?

The final On-Premises client, version 2.63, expired on October 23, 2025, per Meta's sunset page. From that date it could no longer send messages to WhatsApp users. Earlier milestones were the last feature release with version 2.53 on January 9, 2024, and the end of new number registrations on July 1, 2024.

Did moving to the Cloud API change my number or templates?

No. Meta's migration guide said a number moved from the On-Premises API to the Cloud API kept its display name, verification status, quality rating, templates and WhatsApp Business Account. What changed was the integration: endpoints, authentication, webhooks and hosting. Message history stored in your own database did not transfer.

Can I still host the WhatsApp Business API on my own servers?

Not Meta's messaging service itself. The official platform now runs only on Meta's Cloud API. You can host your own application layer, store every webhook in your own database, and turn on Meta's local storage setting to keep message content at rest in a chosen region. Self-hosted "WhatsApp APIs" offered today are not Meta's product.

What does WhatsApp error 1005 mean?

On the On-Premises API, error 1005 was returned when trying to register a business phone number after July 1, 2024, when Meta stopped allowing new On-Premises registrations. Any number that needs the official platform now has to be registered on the Cloud API instead, directly or through a provider.

---

The On-Premises API is history, but its leftovers in code, servers and contracts are not. Clean them up, then build on what works now. If your next step is a shared inbox on your own number, see what Tenashi includes.