What a WhatsApp API costs in a real first month

A price list answers what a number costs. It does not answer what your first month will cost, because the number you connect, the media you send and the moment in the month you connect all move the total. This post works four real months out loud, with every line item, so you can build a budget before you build anything.

#The parts of a first month

Four things can appear on a first bill, and only one of them is the headline price.

1. Accounts. Every number that reached ready and is still linked. One waiting to be scanned is not billed.
2. A partial period. An account connected on the 20th is billed for the days left, not the whole month.
3. Credits. An account removed mid-period comes back as a credit on that invoice.
4. Support, if you bought it. Response targets and an uptime SLA are sold apart from usage.

Proxy traffic is not on the list. It is part of the account price, up to a fair use of 5 GB per number a month, pooled across the organization, with no per-GB line.

type Bill = {
  accounts: number
  accountCents: number
  proxyBytesUsed: number
  proxyBytesFairUse: number
}

function total(bill: Bill): number {
  return bill.accountCents
}

Everything on that object is derived from the same tiers that the invoice uses, which is the only way a budget matches the bill. The proxy fields are there to watch, not to price.

#Month one: one number, text only

The smallest real setup. One support line, one operator, text and the occasional link.

A single account gets up to 5 GB of proxy a month. A support line sending text and a few links a day uses a small fraction of that. This is the cheapest useful setup there is, and it is the right way to check that the whole flow works before you build a platform around it.

#Month two: four numbers, with images

A small agency with four customers, each with their own number, sending order confirmations and some product photos.

Four numbers is where people expect a plan jump and do not get one. There is no "6 number plan" to be pushed onto: each band prices its own accounts, so four numbers cost exactly four numbers.

The proxy line grows with media, since media is what moves the bytes, but it stays at zero. What you watch is how close the month gets to the pool, because past it the numbers pause until the month ends.

#Month three: fifty numbers

A SaaS with one number per paying customer, now past the first band.

At 50 numbers the pool is 250 GB, which covers a text-and-light-media product comfortably. The bill is all accounts, and the average account is about $5.29.

The thing worth planning for is the transition. The 51st number costs $4.10, not $5.25, and it also raises the proxy pool by 5 GB. Both changes land on the same invoice.

#Month four: two hundred numbers

A platform reselling WhatsApp to its own customers, one number each.

The average account is about $4.40. The third band does most of the work, which is the point of graduating rather than discounting.

At this size the organization is billed for every project it runs, and GET /v1/usage/by-project returns accounts, proxy bytes and messages per project per month, so you can rebill each customer however you like.

#Month five: a platform billing its own customers

At this size you are no longer buying WhatsApp, you are reselling it, and the question changes from what does it cost to how do I pass it on. Two things make that possible, and both are on the projects and API keys page.

• A project per customer. Every project has its own accounts, its own key, its own webhooks and its own limits, while the organization pays for all of them together.
• Per-project usage. GET /v1/usage/by-project gives you accounts, proxy bytes and messages per project per month, which is the input to your own invoice.

A customer on one number costs you $7 and you can bill them whatever you want. A customer on ten numbers costs you $54.25. The band boundaries are your margin, and they are public, so there is no argument with a customer about what a number costs.

const usage = await wuapi.usage.byProject({ month: "2026-09" })
for (const project of usage.items) {
  console.log(project.projectId, project.accounts, project.proxyBytes, project.messages)
}

The thing to get right is not billing for messages. Sending is not a unit on your bill either, so a customer who sends more does not cost you more, and charging them per message means inventing a cost you do not have.

#How the four months compare

Two curves, both falling. The unit price falls because the bands graduate, and the average falls faster because more of your accounts sit in the cheap band.

Nothing in that line is a billable event except ready. A message that fails to send costs the same as one that lands, because sending is not the unit.

#Sizing the proxy line before you get it

Proxy traffic never adds to the bill, but the pool has an edge: when an organization's traffic reaches the fair use in a month, its numbers pause until the month ends. Here is a way to know where you stand that does not need a spreadsheet.

Media is what moves bytes, and text is close to nothing. A text message over a proxied connection costs the message and a few kilobytes of overhead, so a busy text-only support line stays far inside 5 GB per account per month. An account sending product images, or a document on every order, is a different shape entirely.

The number to have in your head: across our numbers the average uses about a twentieth of the fair use, and about 99% stay inside it. If you are unsure which kind you are, count the media you send per order and multiply by the orders you expect, and write to support before a launch that is mostly video.

There is a second thing worth knowing about how the pool behaves. It counts the highest number of billable accounts you had in the month, so adding accounts raises it at once, and removing them later does not take it back.

#Reading your own usage

Two calls answer the two questions a cost review actually asks: what am I connected, and what have I pushed through the proxy.

import { Wuapi } from "@wuapidev/sdk"

const wuapi = new Wuapi({ apiKey: process.env.WUAPI_API_KEY })

const accounts = await wuapi.accounts.list()
const billable = accounts.items.filter((a) => a.status === "ready")
console.log("billable accounts:", billable.length)

const usage = await wuapi.usage.get({ period: "month" })
console.log("proxy bytes:", usage.proxyBytes)

Compare proxyBytes with 5 GB times your highest billable count this month: that is how much of the pool is left. Billing in the dashboard shows the same figure as a bar, and nothing about it reaches the invoice.

#The three months that are easiest to get wrong

Three situations account for most of the bill shock people report, and all three are mechanical rather than mysterious.

Crossing a band. The 51st number drops to $4.10, and it also raises the pool by 5 GB. Both land on the same invoice, so a change in cost is expected rather than a mistake. Expect it a month before you hit it.

Growing and pruning in the same month. Each account is prorated for the days it was billable, so a number you added and removed still appears on the invoice for those days. Your average per account will look worse than the band table suggests. It is a timing artifact, not a price change.

A media-heavy launch. A month where you add video-heavy accounts uses more of the pool than text-heavy months ever did. The bill does not move, but a pool that runs out pauses the numbers, so size it with the method above before the launch.

None of these are traps. They are all visible in a usage call, and all three are cheaper to look at before the month than after.

#Where the money actually goes

The branch that surprises people is the middle one, because it never reaches the invoice. Traffic is metered from the moment the account is live, so an account that is connected and idle still uses a little. The pool covers that and far more.

#What a year looks like, if nothing changes

Worth doing once, because it is the number that makes the argument internally. A single number left connected for a year, at $7 a month, is $84. Fifty numbers is $3,171. Two hundred is $10,551.

Nothing in that table moves with your traffic, which is the property that makes it useful in a plan. A per-message provider cannot produce this table without knowing your volume, and that is the difference between a cost you can put in a budget and a cost you can only report on afterwards.

The three ways this changes are all worth writing down when you do the exercise: your customer count grows, your account count is pruned because customers leave, or you cross into a new band and the average moves. None of them is a surprise if the model is per account, and all three are awkward if the model is per message.

#What to do before you commit

Ask a provider for their bill at your own number, at ten times that, and at your realistic year-two number. Then ask three questions.

• What is the unit? Per message, per conversation, or per connected number.
• Is the exit included? A residential proxy that is not in the price is a cost you will meet later.
• What happens at the band edges? Graduated pricing that reads clearly beats a plan you have to grow into.

#Where to go next

The pricing page has the calculator for your own number count. WhatsApp API pricing is about the units and why they are not interchangeable, and choosing a WhatsApp API provider is the list of questions to ask before you trust any of this.