WhatsApp service messages stop being free on October 1, 2026

What does October 1 add to your bill?

Multiply your monthly count of free-form replies sent inside the window by the utility rate of each recipient market. The volumes are the hard part and they come from your own message history; the rates come from Meta's official rate card. A support conversation of six replies becomes six charges where it used to be zero.

The method is four steps. Take the last 30 days of outbound messages, because a full month absorbs weekday and campaign effects. Keep only the ones that were free, which is your service traffic. Bucket them by the recipient's country, since a single blended total will mislead you by an order of magnitude. Multiply each bucket by that market's utility rate.

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 entire population you are counting. Count distinct message IDs rather than status rows, because one message produces several statuses and Meta redelivers webhooks. And bucket by the recipient's country, not yours: the rate follows the person receiving the message.

We publish no rate figures on this page on purpose. Meta has not released the October rates yet, and the secondary sources that claim to have them disagree with each other on the same markets. Take your volumes to Meta's official rate card and do the multiplication there.

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. 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.

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