How to choose a WhatsApp API provider

Almost every comparison of WhatsApp API providers is a listicle with logos. This is the other thing: a checklist you can run against any provider, including a self-hosted one you are running yourself, and the answer that tells you something about how they will behave in year two.

No provider is named here. The questions are the same whoever you ask, and the answers are what you are buying.

#1. What is the unit of charge?

Ask first, because everything else depends on it. Per message, per conversation, per connected number or per user are all real models and they diverge fast as you grow.

A good answer names the unit, gives the price for that unit, and says what happens when you cross into the next band. "From six dollars" is not an answer until you know what six dollars buys.

#2. Is the network exit included, and where does it come from?

A WhatsApp session connects from somewhere. If that somewhere is a datacenter address, the number looks different every time it reconnects, and a number whose network identity changes is one of the things that gets restricted.

Ask whether a residential exit is included, in which countries, and what happens when the exit is down. A provider that answers "the account stays offline rather than connecting from a datacenter address" is telling you they thought about it.

#3. What are the send limits, in writing?

Every provider has a per-number rate limit. Most do not publish it. Ask for the actual number, and whether the recipient must have written first.

• A published limit, per number, per minute, that you can change per account.
• A separate lower limit for people who have never written to the number.
• A documented queue, so a burst waits instead of failing.

A provider that will not state the limit is still enforcing it. You just find out on a Tuesday.

#4. Are webhooks signed, and how do you verify them?

Inbound is where a provider's engineering shows. You need three specific answers: is there a signature header, what algorithm, and what exactly is signed.

The version you want is a timestamp and a signature over the raw request body, with a tolerance window so an old request cannot be replayed at you. A provider that signs a parsed field, or that offers no signature at all, means you are trusting the open internet with the ability to fake a message from your customer's number.

#5. What happens when your endpoint is down?

Ask how many delivery attempts there are, and how long the gaps between them. A retry schedule with named intervals, ending in a dead letter you can read, is the answer.

1{2  "type": "webhook_delivery",3  "endpoint": "https://example.com/webhooks/wuapi",4  "attempts": 6,5  "retryDelaysMs": [30000, 120000, 600000, 3600000, 21600000],6  "verifiesSignature": true7}

Anything less and you will lose events exactly when your server is having a bad day, which is a coincidence you do not control.

#6. Can you make a send safe to retry?

An integration that sends a message from a queue needs to retry when it does not get an answer. Without idempotency, a retry sends twice, and your customer sees it twice.

Ask for an idempotency key, how long it is remembered, and what happens if the same key arrives with a different body. Twenty-four hours is the number to look for.

#7. Is there a typed contract, or just documentation?

Two kinds of provider exist. One has a real contract: a typed SDK, a machine readable specification, consistent error codes, consistent list shapes. The other has prose documentation and an example per endpoint.

The first one saves you a week on a six person team. Check for a machine readable API description, a typed client in the language you use, and errors shaped the same way everywhere.

import { WuapiError } from "@wuapidev/sdk"

try {
  await wuapi.messages.send({ accountId, to: "+584241112233", text: "hi" })
} catch (err) {
  if (err instanceof WuapiError) {
    // Every endpoint returns {code, message, details?} and reuses the same code
    // for the same situation, so you branch on code and nowhere else.
    console.log(err.code, err.message)
  }
}

#8. Are you independent of the phone company?

This one is about who you are actually depending on. A provider that is a business partner of the platform vendor is following that vendor's roadmap and policy changes. An independent provider is making the same bets on a different set of rules.

Ask what happens to your numbers if the vendor changes a commercial term or a policy. The honest answer is a little uncomfortable.

#9. Can you leave?

The last question, and the one that costs you the most to skip. Ask what happens to your number when you cancel, and what happens to the chats and contacts you stored.

• The number stays linked and working through the end of the period you paid for.
• A documented export of your messages, contacts and accounts.
• No charge to leave, and no number held hostage.

A provider whose answer to "what if I leave" is vague is not a provider you should build a platform on.

#The scorecard

#What the questions are really asking

Underneath the nine items there are three things you are buying, and it is worth being clear about which one you are optimising for.

Price is the third of these. It is the one everybody compares and the one that stops mattering when the other two work.

A useful test: ask each provider what their paging procedure is. The answer tells you whether the people who wrote the code are the people on call, and it takes one question. A provider with a real runbook names a threshold, a rotation and a customer communication step. A provider without one says something about uptime that turns out to mean a support queue.

#Self-hosted is a fourth option

Running it yourself is a real choice with real consequences, and the same nine questions apply with you as the answer.

• You operate the servers, and the sessions that fall over at 3am.
• You source and rotate proxies, per number, and keep a number's exit consistent.
• You build the pacing, or you do not have it.
• You keep up with the protocol, which changes without notice.

Self-hosting is free in the way that your own time is free. It is the right call for a team that wants to operate WhatsApp, and the wrong one for a team that wants to ship a product.

#The tenth check, and it is a document

Everything above is a question you ask. This one is a page you read, and it is the most efficient of the ten.

Every honest provider has a list of what it does not support, and reading it against a competitor's silence tells you more than a sales call will. The inconvenient limits are the informative ones: if a page lists message templates as unavailable, or edit windows as fixed, or delete-for-me as impossible, you are reading about real engineering rather than marketing.

The list of what wuapi does not support is a fair sample of what that page looks like. It names the limits, the reasons and the workarounds, and it is one of the reasons the rest of the documentation is worth reading.

#The questions, in the order to ask them

Most evaluations stall because the nine questions are asked in a random order and the provider gives the same paragraph each time. Asking them in this sequence gets a specific answer faster, because each one narrows the next.

1. What does one number cost when it sends nothing? You get the unit, the rate, and whether there is a plan.
2. Is a residential exit included, and what happens when it is down? You find out whether they thought about network identity at all.
3. What are the send limits per number, per minute? A provider with real engineering has a number. A reseller does not.
4. Are webhooks signed over the raw body? If yes, ask for the retry schedule. If no, stop reading and keep looking.
5. Is there an idempotency key, and for how long? Twenty-four hours is the number that shows they have thought about retries.
6. Is there a typed SDK and a machine readable spec? This is the question that decides how much of month one you spend reading prose.
7. Are you independent of the platform vendor, and does the terms page say so? A page that cannot answer is an answer.
8. What happens to my numbers if I leave mid-period? Ask last, because it is the question that reveals whether support is a department or a person.

The order is deliberate. Price tells you the unit, the unit tells you the growth curve, the growth curve tells you which limits will bite, and the limits tell you whether the engineering is real.

#Questions people ask

#Where to go next

WhatsApp API pricing covers the units in detail. What a WhatsApp API costs in a real first month works the numbers out at four sizes. If you are deciding between a linked device and the official platform, linked device or Cloud API is the comparison.