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

Five things can appear on a first bill, and only two of them are the headline price.

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

type Bill = {
  accounts: number
  accountCents: number
  proxyBytesUsed: number
  proxyBytesIncluded: number
  proxyCents: number
}

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

Everything on that object is derived from the same tiers and the same proxy rate that the invoice uses, which is the only way a budget matches the bill.

#Month one: one number, text only

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

A single account gets 0.5 GB of proxy. A support line sending text and a few links a day uses a small fraction of that, so overage does not appear. 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 overage line is the new one. Media is what moves the bytes. At 0.4 GB past the pool, it is close to forty cents, and it is the number to watch as the account count grows.

#Month three: fifty numbers

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

At 50 numbers the pool is 25 GB, which covers a text-and-light-media product comfortably. The bill is now dominated by accounts, and the average account is about $4.53.

The thing worth planning for is the transition. The 51st number costs $3.50, not $4.50, and it also raises the proxy pool by 0.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 $3.76. 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 $6 and you can bill them whatever you want. A customer on ten numbers costs you $46.50. 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

The overage is the one line nobody can predict from a price page, because it depends on what your numbers send. Here is a way to size it 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 well inside 0.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: 0.5 GB is a real allowance for a text-first integration and a rounding error for a media-first one. If you are unsure which you are, count the media you send per order and multiply by the orders you expect.

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 the allowance at once, and removing them later does not take back what it already included. Growing is therefore cheaper per account than shrinking and regrowing, which is the opposite of how a per-message bill behaves.

#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, "included:", usage.proxyBytesIncluded)

proxyBytesIncluded is the pool your highest billable count earned you this month, and the difference between the two numbers is what appears on the next invoice. If that difference is not zero, this is the call to make before adding accounts rather than after.

#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 $3.50, and it also raises the pool by 0.5 GB. Both land on the same invoice, so a jump in cost is expected rather than a mistake. Expect it a month before you hit it.

Growing and pruning in the same month. The pool counts your highest billable count, so a number you added and removed still raised the allowance for that month. 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 image-heavy accounts has a proxy line that text-heavy months never produced. If you do not know which kind of month you are having, read what a WhatsApp API costs again for the sizing method, because the number is knowable in advance.

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

#Where the money actually goes

The branch that surprises people is the middle one. Traffic is metered from the moment the account is live, so an account that is connected and idle still uses a little. The included pool covers that. Past the pool, idle time costs money too.

#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 $6 a month, is $72. Fifty numbers is $2,718. Two hundred is $9,018.

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.