Move WhatsApp sending from Plivo to WhaBuzz

Moving WhatsApp sending from Plivo to WhaBuzz means changing your send code and your webhook handler, not your customers' conversations. Plivo wraps WhatsApp in its own Message API, while WhaBuzz accepts Meta's request bodies unchanged. This post maps one to the other and gives a cutover order that avoids dropping inbound messages.

What changes when you leave Plivo?

Three things change: the request, the webhook and the bill. The WhatsApp Business Account (WABA) and its approved templates can carry over if the account is yours.

According to Plivo's WhatsApp FAQ, a WABA created through Plivo's onboarding "is created with Plivo as the partner". Per the same page, from 1 Nov 2026 Plivo charges a platform fee per WhatsApp message for both inbound and outbound messages, plus a monthly fee per WABA. Its pricing page lists $0.0010 per message and $10 a month per WABA. WhaBuzz charges ₹500 a month for the first number and nothing per message, as the pricing page states.

What does not carry over: inboxes, chatbot flows, contact lists, opt-in tracking and your old provider's message history. WhaBuzz is an API and starts its log when you connect. Keep opt-out state in your own system. Compare the two vendors in full on WhaBuzz vs Plivo.

How does a Plivo send differ from a WhaBuzz send?

Plivo sends WhatsApp through its general Message API. Per its send-a-message reference, type takes sms (default), mms or whatsapp, src is your WhatsApp Business number, dst is the recipient, template carries the template object and url is a callback for delivery status. Plivo's template example looks like this:

client.messages.create({
  src: "+14151112221",
  dst: "+14151112222",
  type: "whatsapp",
  template: template,   // { name, language, components: [...] }
  url: "https://foo.com/sms_status/"
});

WhaBuzz takes Meta's /messages body plus a from field, as the messages guide describes. The equivalent template send from the migration guide:

{
  "from": "1013622581841046",
  "to": "16505551234",
  "type": "template",
  "template": {
    "name": "renewal_reminder",
    "language": { "code": "en" },
    "components": [{ "type": "body", "parameters": [{ "type": "text", "text": "Kerry" }] }]
  }
}

Send it with POST /v1/messages and Authorization: Bearer $WHABUZZ_KEY. The mapping:

Which fields need care?

The template name and language stay the same, because approved templates are synced by name and language. Check the components array against Meta's message reference. Plivo's example passes a header media parameter as "type": "media" with a URL; confirm each parameter type against Meta's reference rather than copying it across, because WhaBuzz forwards your body to Meta untouched and Meta decides what is valid.

Phone formats differ too. Plivo's examples use a leading plus (+14151112222). The WhaBuzz examples use digits only (16505551234).

Add an Idempotency-Key header to each send so a retry in your own code cannot send twice. See idempotency and the post on webhook reliability.

How do webhooks differ?

Plivo sets WhatsApp webhooks at the WABA level. Per its FAQ, you open WhatsApp settings, set the webhook URL and select events, and "webhooks apply to all numbers and templates under the WABA". Per-message status callbacks go to the url you pass on the send. Plivo signs requests with X-Plivo-Signature-V2, X-Plivo-Signature-Ma-V2 and X-Plivo-Signature-V2-Nonce headers, per its signature validation page.

WhaBuzz signs with a single X-WhaBuzz-Signature header: an HMAC-SHA256 of {t}.{raw body} keyed with your endpoint's secret. Each event is one envelope. The data field holds Meta's change value and raw holds Meta's full POST. Statuses arrive as Meta's sent, delivered, read and failed, one event each, unordered.

Rewrite your handler to verify the new signature, store the event, answer 2xx, and deduplicate on dedupe_key. The webhooks guide has the retry ladder and replay.

How do you move the number?

First check who owns the WABA in Meta Business Manager. If it belongs to your business, connect it to WhaBuzz yourself through Embedded Signup in the console, or with POST /v1/numbers/connect. If Plivo is the partner on the WABA, the migration guide says to ask them to transfer it to your business, or migrate the number to a WABA you own using Meta's number migration. Plivo's FAQ lists "Request migration through Plivo" and "Follow Meta's migration requirements" for numbers from another provider.

POST /v1/numbers/migrate moves a number from a different provider's WABA to yours. Then import templates with POST /v1/templates/sync. See numbers for connection states.

In what order should you cut over?

Follow the steps from the migration guide, in order:

1. Check who owns the WABA.
2. Connect it to WhaBuzz.
3. Import templates.
4. Add a webhook endpoint and verify it. Keep Plivo's webhook receiving until you cut over.
5. Change your send code.
6. Change your inbound handler.
7. Cut over: WhatsApp delivers inbound messages to one webhook subscription per app at a time, so subscribing the WABA to WhaBuzz moves inbound delivery.

Do step 7 at a quiet hour. Send a test message to the number and confirm a message.inbound event arrives.

Cutting a number over has a short window where inbound messages go to neither provider.

Keep the Plivo account open until you have seen traffic on WhaBuzz. WhaBuzz offers a sandbox with test keys for rehearsing steps 5 and 6.

Related reading

• Migrating from Plivo or WATI is the reference for the steps above.
• Webhooks guide covers signatures, retries and replay.
• WhaBuzz vs Plivo compares fees and scope.
• WhatsApp webhooks that never lose an event covers the inbound handler.
• WhatsApp API overview covers provider basics.