WhatsApp marketing software vs a self-hosted API: which one do you actually need?

Most articles ranking for "WhatsApp marketing software" are written by WhatsApp marketing software companies. This one isn't, and the conclusion is going to be inconvenient for us in about a third of cases.

We build WaSphere — an open-source, self-hosted WhatsApp API. It is a developer tool, not a marketing suite. If you searched for marketing software, there's a real chance you should buy marketing software. This piece is about telling the difference honestly, and then, if a self-hosted API is genuinely the right answer, showing what building on one actually involves.

Two different products that both "send WhatsApp messages"

A WhatsApp marketing platform sells you a finished workflow. You log in, upload a list, pick a template, choose a segment, schedule a send, and watch a dashboard fill with delivery and read rates. Somebody else operates the infrastructure, keeps the Meta integration current, and takes the support call when a campaign fails at 2am.

A self-hosted WhatsApp API sells you a primitive. It exposes endpoints — send a message, receive a webhook when one arrives, manage sessions and contacts. What happens between "I have 4,000 customers" and "they each got the right message on Friday" is code you write.

Both send WhatsApp messages. So does curl. The distance between them is everything that isn't sending.

What a self-hosted API gives you

Concretely, using our own API as the example, this is what you get out of the box:

Sending. Fourteen message types over one URL pattern — text, image, video, audio, document, gif, sticker, location, contact card, poll, buttons, list, view-once, reaction.

curl -X POST "https://api.yourdomain.com/workspaces/{workspaceId}/proxy/api/sessions/promo/messages/image" \
  -H "Authorization: Bearer wsk_your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "923001234567",
    "url": "https://yourcdn.com/campaigns/june-sale.jpg",
    "caption": "20% off everything until Sunday. Reply STOP to opt out."
  }'

A contact book with tags. Every number that messages you lands in it automatically; you can also add numbers yourself, tag them, attach notes, and import a CSV (up to 2,000 rows per import, additive and non-destructive — re-running the same import is safe). Tags are how you segment:

curl "https://api.yourdomain.com/workspaces/{workspaceId}/contacts?tag=VIP&limit=100" \
  -H "Authorization: Bearer wsk_your_key"

Send pacing. Every session applies a random 4–12 second delay before each outgoing message by default, plus an optional per-minute ceiling. Not a marketing feature — a survival feature. See anti-ban controls.

Webhooks for everything inbound, HMAC-signed, so replies and delivery receipts flow into your own systems.

A shared inbox and server-enforced roles, so replies to a campaign don't land in one person's phone.

Multiple numbers in one deployment, isolated from each other.

What it does not give you

This is the part the comparison posts skip. A self-hosted API — ours included — does not ship:

• A campaign builder. No visual composer, no audience picker, no preview-and-schedule screen. You write a script.
• A scheduler or drip sequences. There is no "send Tuesday at 9am" and no "three days after signup, send message two". That's your cron job and your state machine.
• Marketing analytics. No open-rate charts, no funnel view, no per-campaign attribution, no revenue reporting. Delivery events arrive as webhooks; turning them into a dashboard is a project.
• Link tracking or A/B testing. Nothing shortens your URLs, attributes a click, or splits an audience for you.
• Opt-out management. Nothing parses "STOP" and suppresses that number on the next send. You must build this — and legally, in most markets, you must have it.
• Deliverability as a service. Nobody is monitoring your sender reputation on your behalf.

None of that is a criticism of the tool. It's the definition of the category. An API is a building material.

The honest decision

Buy WhatsApp marketing software if your team is marketers rather than engineers, you want campaign analytics on day one, you're sending promotional broadcasts to lists at scale, you need someone else accountable for deliverability, or the total cost of one engineer maintaining an integration exceeds a platform subscription. For most marketing teams at most companies, this is the correct answer, and you'll be live in a week instead of a quarter.

Run a self-hosted API if at least one of these is true and you have someone to write the code:

• Data residency. Customer conversations cannot leave your infrastructure — a hard requirement in healthcare, finance, and a growing number of jurisdictions. This is the argument that no amount of platform polish answers.
• Your messaging is transactional, not promotional. Order updates, OTPs, appointment reminders, delivery notifications. These are triggered by your systems, they don't need a campaign builder, and per-conversation pricing on a high volume of them adds up fast.
• You're a software vendor. WhatsApp notifications inside your own product, for your customers, under your brand. A marketing suite is the wrong shape entirely — you need an API you can embed.
• You resell or run many numbers. An agency handling fifty clients pays for fifty platform seats, or runs fifty isolated sessions on one deployment.
• The messaging is genuinely custom. Two-way flows with buttons and lists, driven by your database, that a template-based campaign tool can't express.

Run both — this is more common than either camp admits. Marketing platform for promotional broadcast; self-hosted API for transactional traffic and product notifications. They're different workloads with different economics, and nothing says one vendor must own both.

If you build it: the four things people underestimate

Say the decision came out on the self-hosted side. Here's what the build actually contains beyond POST /messages/text.

1. Opt-out, and it's not optional. You need to catch the reply, suppress the number, and honour it on every future send. The minimum version is a webhook handler that tags the contact:

const OPT_OUT = /^(stop|unsubscribe|sair|cancelar)$/i;

if (OPT_OUT.test(data.content?.text?.trim() ?? '')) {
  await fetch(`${BASE}/contacts/bulk`, {
    method: 'POST',
    headers: { Authorization: `Bearer ${KEY}`, 'Content-Type': 'application/json' },
    body: JSON.stringify({ ids: [contactId], action: 'addTag', tag: 'OptedOut' }),
  });
  await text(phone, "You're unsubscribed. You won't get promotional messages from us.");
}

Then filter on that tag before every campaign. Build this on day one, not after the first complaint.

2. Pacing, and the arithmetic that follows from it. With the default 4–12 second delay you average roughly 7–8 messages a minute per session. That is about 450 an hour. A 5,000-person list is therefore an eleven-hour send on one number, not a click. Plan for it: run overnight, split across sessions, or accept the window. Turning the delay down to go faster is exactly the behaviour that gets numbers banned.

3. Ban risk on unofficial connections is the real constraint. The Baileys engine talks to WhatsApp's unofficial web protocol. It's free and has no 24-hour window, but a number can be blocked and no gateway can promise otherwise. For high-volume promotional messaging to people who did not explicitly opt in, no delay tuning saves the account. That workload belongs on the Meta Cloud API with approved templates, where the rules are enforced up front instead of by a ban. WaSphere supports both engines per session — a support number on Baileys and a promotions number on Meta in the same workspace — but if all your traffic is promotional, you're paying Meta either way, and a marketing platform starts to look reasonable again.

4. Templates and the 24-hour window. On the official API you can only send free-form messages within 24 hours of the person's last message to you. Outside it, you need a pre-approved template:

curl -X POST "https://api.yourdomain.com/workspaces/{workspaceId}/proxy/api/messages/template" \
  -H "Authorization: Bearer wsk_your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "447700900123",
    "name": "order_update",
    "languageCode": "en_US",
    "bodyParams": ["Ali", "A123", "shipped"]
  }'

Approval takes time and templates get rejected. Any plan that assumes you can improvise copy on the official API is wrong.

The cost question, stated carefully

We won't quote other vendors' prices — they change, they vary by region and volume, and half the "comparison tables" on this topic are out of date the week they're published. Price your own case directly.

What we can say about the structure: a self-hosted deployment has no per-message fee to us — WaSphere is MIT-licensed and you run it. Your costs are a server, storage, and engineering time. A marketing platform charges a subscription and usually passes through Meta's per-conversation fee. On the official Cloud API, Meta's conversation charges apply regardless of which route you take.

Which is cheaper depends entirely on volume and on how you value an engineer's week. At low volume, a platform almost always wins on total cost. At high transactional volume, self-hosting usually does. The crossover is real but it's specific to you, and anyone who quotes it as a universal number is selling something. Our own pricing is public if you want the baseline.

The short version

If you need campaigns, analytics, and no engineering, buy a WhatsApp marketing platform. If you need control, data residency, custom flows, or transactional messaging at volume, run your own API. If you need both, run both — that's not a compromise, it's the correct architecture.

Next

• Send messages — every message type, with examples
• Contacts — tags, notes, CSV import and export
• Anti-ban controls — what pacing does and doesn't prevent
• Meta Cloud API — the official-API route, per session
• Build a WhatsApp chatbot with code — the two-way side of this

Everything above is open source. If any of the trade-offs here look wrong for your case, read the code and judge for yourself — that's the point.