WhatsApp service messages stop being free on October 1, 2026

What does October 1 add to your bill?

For each business phone number, drop the first 1,000 service messages of the month, then multiply what remains by the utility rate of each recipient market. Split in-window utility templates out first: they do not share that allowance. The volumes come from your status webhooks; the rates are on Meta's official October 1, 2026 card.

The method is five steps. Take one calendar billing month of outbound messages, not a trailing 30-day window. A full month absorbs weekday and campaign effects, and the 1,000 allowance resets each calendar month. A window that straddles two months understates the free tier: 600 deliveries before month-end and 600 after look like 200 billable if you drop 1,000 from the combined 1,200, even though each month stayed under its own allowance. Count from status webhooks, not from send calls: a send log tells you how many messages went out, only the status data tells you which ones were free, and the free ones are the population you are counting. Count distinct message IDs rather than status rows, because one message produces several statuses and Meta redelivers webhooks.

Split that population by `pricing.category`. Until October 1 both service replies and in-window utility templates come back with `type: free_customer_service`, so a type-only filter mixes two bills. Keep `category: service` as your service traffic. Keep `category: utility` as in-window utility templates: they get volume tiers and they do not share the 1,000 free service allowance.

The 1,000 free service messages apply per business phone number, not per country. For each phone number, sort its service messages in delivery order, drop the first 1,000 in the month, and only then bucket what remains by the recipient's country. Subtracting 1,000 from every country bucket overstates the allowance. A blended total with no country split will mislead you by an order of magnitude. Multiply each remaining country bucket by that market's utility rate. Utility templates inside the window skip this allowance step: they bill at the utility rate with volume tiers from the first message.

We publish the October figures Meta released on September 1, 2026, copied from its official USD rate card (header: "effective October 1, 2026"). Service matches utility in each market. Mexico $0.0085, Colombia $0.0008, Argentina $0.026, Brazil $0.0068, Chile $0.02, Peru $0.03, Spain $0.02, United States (North America on Meta's card) $0.0034, all USD per delivered message. If a figure here and Meta's card ever disagree, Meta's card wins.

Now the part most coverage of this change gets wrong. Per conversation, this is cents. Six replies at a typical LatAm utility rate is a few cents, next to the dollars an agent already costs you in model usage or the tens of dollars a human costs in time. No single conversation gets meaningfully more expensive. What makes October a budget line is volume: a hundred thousand support conversations a month turns cents into a number your finance team will ask about. The chatbot cost calculator runs the all-in math with your own numbers.

What is still free after October 1?

Inbound messages, at any volume. The first 1,000 service messages per business phone number each month. Conversations opened from a click-to-WhatsApp ad, which carry a 72-hour free entry point window. And failed messages, because Meta bills on delivery, so a number that is not on WhatsApp or a user who blocked you costs nothing. Utility templates inside an open window are not on this list from October 1.

The free monthly service allowance is new. Each business phone number gets 1,000 free service messages a month; unused ones do not carry over. Count from the 1,001st when you size the bill. Utility templates sent inside an open 24-hour window leave this free list on October 1: Meta's pricing page now says they are charged from that date, closing the exemption that had been in force since July 2025.

The free entry point is the lever most teams forget. A conversation that begins when someone taps a click-to-WhatsApp ad comes back on the status webhook with the pricing type `free_entry_point`, and it stays free for 72 hours rather than 24. If you already buy those ads, that traffic is not affected by October at all, and the gap between 72 hours and 24 is worth designing around.

Failed messages matter for a less obvious reason. The send call returns a message ID for messages that later fail, so your send log counts them and Meta's invoice does not. The two disagree by exactly your failure rate, and that gap only becomes visible if your cost reporting is built on statuses.

Which brings up the field that decides everything. The status webhook carries a `pricing` object with `category`, `type` and `billable`. They are easy to conflate and they answer different questions. `category` says what the message is; `type` says how this particular one was charged. A service message today carries `category: service` and `type: free_customer_service`, and October changes only the second one. `type` is the authoritative field. `billable` is a legacy boolean Meta is deprecating, so read it only as a fallback for old payloads and never build new logic on it.

The practical consequence is that your send log is not your bill, and it never was. Any cost report has to be built from status webhooks. If you drop status webhooks, you are not losing delivery data, you are losing billing data.

What we changed in our own stack

We run our own CRM on the WhatsApp Business Platform, so we audited our own agent first. One pattern in our code costs nothing today and will cost from October: automatic chunking of long replies into several sends. A second one we expected to find turned out not to be billable at all, and that distinction is worth more than the finding.

Chunking was not a mistake when it was written. WhatsApp caps message length, so a long reply has to be split somewhere, and it was free, so nobody counted the splits. From October each split is a separate charge, which makes the split point a cost decision rather than only a formatting one.

The pattern we expected to find beside it was the typing rhythm, and it is not billable. Our agent keeps a typing indicator alive while it works, and we assumed that was outbound volume. It is not: the call sets `status: read` with a `typing_indicator` flag against the inbound message id. It carries no recipient and no content, produces no outbound message id, and so is not a service message. Teams that simulate the same effect by sending several short messages will be billed for every one of them, which is the version worth auditing. Check which of the two your stack does before you disable anything, because turning off the free one costs you the experience and saves nothing.

The second change was to reporting. Cost per conversation has to be keyed on the status webhook, not on the send, or the report and the invoice disagree by the failure rate. That is a small change to make now and an unpleasant one to make in the middle of a billing dispute.

We are telling clients the same thing we did ourselves, in this order: find out what share of your outbound volume is currently free, put a number in front of whoever owns the budget, audit your longest flows for messages that exist only because the previous one was incomplete, and verify that the template categories you are billed for match the ones you registered. If you want that audit run on your operation rather than reading about ours, that is what our customer service agents and our AI SDR guide are built around.

October 1 questions, answered