WhatsApp template categories: why your utility template became marketing

The category decides price, limits and route

The Template categorization page of the Cloud API documentation opens by saying categories exist for pricing purposes, and that is true: since July 2025 Meta charges per delivered message, and the amount depends on the category and on the recipient's country. Marketing, utility and authentication have different prices, and volume tiers only exist for utility and authentication. Changing a template's category means changing the price of every message it sends.

But the category decides more than price. The per-user marketing limit, which returns error 131049 when a person has already received too much marketing from every business combined, applies only to marketing. So does the restriction that blocks marketing delivery to United States numbers. A delivery-update template that becomes marketing starts competing for inbox space with everyone's promotions — and stops reaching customers with US numbers.

And from 2027 the category decides the route. On 13 October 2026 Meta announced on the Overview page of the Marketing Messages API that the Cloud API will stop accepting marketing: Messaging accounts created on or after 13 April 2027 can no longer send marketing through it, and on 13 October 2027 sending marketing through the Cloud API starts returning an error. The same page asks you to check your reclassified traffic, because utility recategorised as marketing must go out through the new API.

Pricing changed shape in October 2026 too. Between July 2025 and September 2026, utility sent with the customer service window open was free; since 1 October 2026 it is charged again, according to the Pricing page. Marketing was never free inside the window. The cost of a recategorisation is therefore simpler to calculate and easier to get wrong: it is the difference between the utility price and the marketing price, on every message, with the window open or closed.

What makes a template utility

Meta's definition has two conditions, and both must hold at the same time. The first is being non-promotional: no intent to sell, persuade or encourage a purchase. The second is being specific to or requested by the user — tied to their order, account, service or transaction — or, instead, being essential or critical to them, such as a security alert. If either one is missing, it is not utility.

The page lists five objectives that fit utility. Opt-in management: confirming a subscription made on another channel, or a request to leave. Order management: confirming, updating or cancelling, with order details in the body — order number, tracking, refund processed. Account alerts and updates about what the customer has already bought or subscribed to. Feedback surveys about a specific purchase or interaction. And continuing on WhatsApp a conversation that started on another channel, as long as the customer asked for it.

Meta's examples help calibrate the line. A notice that the monthly charge will hit the saved card is utility, as is a daily account balance and even a warning that only a few minutes are left on the plan, with the date to top up. The top-up request does not make the template promotional, because it refers to a service the customer already has and needs to know about. The word that tips the scale is discount: the same subscription expiring, with an offer to renew, is marketing.

There are also the essential cases, which do not depend on a customer request but still have to be non-promotional: public safety, such as a severe weather alert; public service, such as health campaigns and voter registration deadlines; disruptions, such as a system outage; account or product protection, such as fraud alerts and recalls; and legal obligations, such as a change to the privacy policy. It is a short list on purpose.

What is marketing even when it does not look like it

Marketing is the most flexible category, and Meta puts in it everything that does not clearly fit the other two. Two rules of thumb come straight from the documentation. Mixed content is marketing: an order update with a promotion, or a feedback survey with an offer, stops being utility because of the promotional part. And unclear content is marketing: a template whose body is only {{1}}, or only “Congratulations!”, gives Meta no way to know what will be sent, and it decides on the broader side.

The third rule is more surprising: retargeting is marketing even when the customer asked for it. The page's examples are the ones that break expectations most. An abandoned cart is marketing. A subscription expiring with a discount to renew is marketing. A pending loan application with an invitation to log in and continue is marketing. A car found through the customer's saved search is marketing. So are birthday greetings and a thank-you for the purchase with a percentage off.

The most counterintuitive example is the apology: telling the customer their delivery was late and that a credit has been deposited in their account is marketing for Meta. The logic is the same as before — the credit is an incentive for the next purchase, and the notice is no longer just a notice. Introducing a new virtual assistant counts as marketing too, because it promotes a service instead of responding to something the customer did.

The rule applies to very common templates. An invoice issued, with amount and due date, is utility; the same invoice with “pay today and get 5% off” is marketing. An appointment confirmation is utility; a reminder that it has been six months since the last visit, inviting the customer to book again, tends to be marketing. Meta itself warns that the examples are illustrative and that similar text may fall into another category depending on the exact content — but the direction is always the same: when in doubt, the scale tips towards marketing.

Authentication, the narrowest category

Authentication is for one thing only: verifying someone's identity with a one-time code. It is also the only category allowed to send that code — an OTP in a utility or marketing template is outside the rules. The requirements are strict: use the authentication templates from Meta's library, configure a code button (copy code or one-tap autofill), use no URLs, media or emojis, and keep parameters to 15 characters.

The recategorisation path here is different, and harsher. When Meta concludes that a marketing or utility template should be authentication, it gives advance notice but does not change the category: on the first day of the following month, the template becomes REJECTED and stops sending. From then on, sending with it fails like sending with any template that is not approved.

The way out Meta recommends is to migrate before the deadline to a library authentication template, not to appeal: templates flagged for rejection because they should be authentication are not eligible for review. If you send verification codes in a utility template out of old habit, the notice is the moment to switch — after the first of the month, the code simply does not arrive.

At creation: the utility template that comes back approved as marketing

When you create a template, you state the category, and Meta checks it against the content. Until April 2025, a disagreement could end in rejection. Since 9 April 2025, a template submitted as UTILITY that Meta considers marketing is approved as MARKETING, without rejection — and the allow_category_change parameter, which for years allowed or blocked that switch, was retired on the same date. Older guides still recommend it as protection. It no longer protects anything.

The consequence is that “approved” no longer answers the question that matters. The category the template was approved with comes back in the creation response and in the message_template_status_update webhook, and that is the one to store — not the one the form asked for. Rejection on category grounds still exists, with the reason INCORRECT_CATEGORY, but the most common case now is the silent one: approved, just in another category.

Two rules from the Utility templates page complete the picture. Creating or editing a utility template with marketing material makes Meta recategorise it automatically as marketing — editing an approved template to add an offer is the shortest way to lose its category. And templates from Meta's library come pre-categorised as utility or authentication; customising one sends the template through review again.

In production: approved is not final

The category also changes after approval. Since July 2024 Meta has run a recurring process that looks for approved templates that should be in another category. In the September 2026 version of the Template categorization page, that process widened: it applies to any approved template that does not meet the guidelines, either because it was approved outside them or “because the messages the template sends do not meet them” — and that includes templates whose category had already been confirmed by a review.

Our reading of this change, which is an inference and not written this way in the documentation: what goes into the variables now counts. A utility template approved with the body “Your order {{1}} has been updated: {{2}}” can be flawless as text and become marketing because of what the integration fills into {{2}} every day. The review approved the mould; recategorisation in production looks at what came out of it.

When Meta concludes that a utility template should be marketing, it gives one day's notice, and at the deadline the category becomes MARKETING. The status stays APPROVED and the template keeps sending — which is what makes the change dangerous. Nothing fails, no send is refused, and every message from that moment on costs as marketing and follows marketing's rules. For businesses that have already received a misuse warning, there is not even notice: since 16 April 2025, the change is instant, and email and webhook only confirm it.

The notice arrives through several channels: email to people with full control of the account, an icon in the template list showing the target category and the date, a banner with a CSV in WhatsApp Manager, a list in Business Support Home and the template_category_update webhook. Of these, only the last one enters your system without anyone opening anything. We have seen it happen in our own operation: a utility template was reclassified as marketing by Meta, and the lesson stayed in the code — the category stored in the database is a copy, and a stale copy makes a campaign's cost estimate lie.

The webhook that warns you, and the field-name trap

template_category_update fires at two moments: when a template's category is going to be changed by the automated process, and when it has been changed, manually or by the process. Both events carry message_template_id, message_template_name and message_template_language. What differs between them are the category fields — and that is where the trap lies.

In the advance notice, the webhook reference lists three fields: correct_category, the category the template will have in 24 hours; category_update_timestamp, the scheduled moment of the change, in Unix seconds; and new_category, which, despite its name, is the current category. In the completed change, the fields are previous_category and new_category, and only then is new_category the new one. If you read new_category in both events as “the category from now on”, you miss the whole notice — and only find out about the switch once it has happened.

The right handling tells the two cases apart by which fields are present. With correct_category and category_update_timestamp, it is a notice: record the scheduled change, alert whoever owns the template and use the 24 hours to decide whether to adjust the text, accept the new category or prepare to appeal. With previous_category, it is done: update the stored category and recompute whatever depends on it — cost estimates, limit rules, the sending route.

If you do not want to depend on the webhook alone, the API lets you check: a GET on message_templates with fields=category,correct_category shows, for each template, the current category and the category it is moving to, when a change is scheduled. And, for every message, the status webhook carries pricing.category — the category that message was actually classified in. That is the source to check a charge against, because it is the one Meta used.

Reviews, penalties and error 131064

You can request a review of a recategorisation, but only through the dashboard. The path goes through WhatsApp Manager: in the template list, the banner leads to Business Support Home, in the template category updates area, where you select the template and request a review. There is no API endpoint for it. The deadline is 60 days from the category change, and the documentation promises no response time. The outcome shows up in tabs: in review, unchanged or reversed — and, if reversed, the template goes back to its previous category.

A reversal is not immunity. Since the September 2026 update, Meta can act again on a template already confirmed by a review if the messages sent afterwards do not meet the guidelines. And businesses that keep classifying marketing as utility enter a ladder of restrictions described on the same page: a warning; a cap on utility volume within a rolling 24-hour window, with the excess rejected, for at least seven days; a utility restriction, in which every approved utility template on the account becomes marketing and creating utility templates is blocked for seven days, or 30 for repeat offenders; and finally the same restriction across every account in the portfolio, for 30 days.

Each step arrives through the account_update webhook, with the ACCOUNT_RESTRICTION event, a violation_type such as UTILITY_TEMPLATE_ABUSE or UTILITY_TEMPLATE_ABUSE_RATE_LIMIT and, when a restriction is active, a restriction_info with the type and the date it expires. This webhook deserves an alert with an owner: it is the only notice that the whole account is now being treated as suspect.

The error that comes with the cap is 131064, which the Error codes page describes as a messaging limit reached due to template classification violations, applying to templates and to Direct Send. The recommended fix is to review your categories; the restriction lifts on its own at the end of the penalty period. A common misconception, repeated by some vendors, is that 131064 blocks all sending. Going by the documentation's ladder, the cap hits utility volume — marketing and authentication keep going out. What gets blocked is precisely the message that should matter most: the transactional notice.

How to write a utility template that stays utility

The rule that settles most cases is to separate. One template for the notice, another for the offer. The order-shipped notice carries the order number, the tracking code and nothing else; the coupon for the next purchase goes in a marketing template, sent to people who agreed to receive marketing. Merging the two to save a message costs more than sending both, because the merged message is marketing in its entirety.

Next, anchor the body in the transaction. Utility is specific, and specificity shows in the text: order number, appointment date, invoice amount, last digits of the card. A generic body with a single variable is exactly what Meta calls unclear content. And now that recategorisation looks at the messages sent, the discipline applies to what the integration puts into the variables, not only to the approved template.

Watch the vocabulary as well. Discount, coupon, don't miss out, new arrivals, limited-time offer and invitations to try another product push a template towards marketing, even inside a legitimate notice. A feedback survey has to name the purchase or interaction it is about; a generic one about the experience with the brand does not pass as utility. And an invitation to continue the conversation on WhatsApp is only utility when the customer asked to switch channels.

Finally, treat the category as live data. Store the category Meta approved, not the one you requested; subscribe to template_category_update, message_template_status_update and account_update; read correct_category as a notice and previous_category as a fact; and check pricing.category when the numbers do not add up. With the end of marketing on the Cloud API set for 2027, knowing each template's current category stops being a billing detail and starts deciding which way the message goes out.