WhatsApp message templates: why Meta rejects yours
The review checks variable placement, prohibited claims, opt-out wording and category fit. Why a misplaced placeholder fails, and how to rewrite it.
· 6 min read
What the review is actually examining
A template submitted to Meta is not read the way a colleague reads a draft. The review looks at four separable things, and knowing which one failed is most of the work of fixing it: the mechanical structure of the message and its variable placeholders, the substance of what the message claims, the wording around consent and stopping messages, and whether the content matches the category declared at submission. A rejection is a verdict on one of those four, not a general judgement that the message was poorly written.
This is why "the wording looked fine to me" is the most common reaction to a rejection. A large share of first rejections are structural: the message reads perfectly well to a person and still fails because a placeholder sits somewhere the format does not permit. Meta describes the review as a combination of automated checks and manual review, which is the practical reason a structural fault is caught instantly and reliably, while a borderline judgement about tone is slower and less predictable.
Separating the four also prevents the most wasteful response to a rejection, which is rewriting the whole message from scratch. A structural rejection needs a structural fix. Rewriting the sentences around a correctly flagged dangling variable changes nothing and burns another review cycle for no reason.
Variable placement, and the failures that are purely mechanical
Variables in a template are numbered placeholders that get filled in at send time, and the rules governing them are strict in ways that have nothing to do with meaning. Placeholders use a double-brace format and must be numbered sequentially from one, with no gaps: a template using the first, second and fifth positions while skipping the third and fourth is rejected on numbering alone, even though a human reader would never notice.
A template also cannot begin or end with a placeholder. A message opening with a bare variable followed by a comma, before any fixed text, has a dangling parameter at position zero and fails. The fix is to add real words around it, so a greeting reads as a greeting rather than as a token the system cannot verify.
The subtler mechanical failure is variable density. A short template carrying five or six placeholders leaves almost no fixed text for the reviewer to assess, and that shape is associated with abuse, because it is what a message designed to be filled with arbitrary content looks like. The documented remedies are to reduce the number of variables or to lengthen the surrounding text so each placeholder sits inside a properly worded sentence. Special characters inside a parameter value, and body text that duplicates an already-approved template word for word, are separately flagged.
Claims and content the policy will not accept
Beyond structure, the review checks what the message actually says against Meta's Commerce Policy and Business Policy. Anything describing goods or services for sale — a price, a fee, a charge, a required disclosure — is treated as a commercial claim and has to be accurate and clear. A price quoted inside a template needs to be the real, current price, not a placeholder figure the business intends to correct later in conversation.
Requests for sensitive identifiers are a hard rejection. A template cannot ask a customer to send a full payment card number, a full financial account number, or a full national identification number. Asking for a partial identifier, such as the last few digits of an account, is permitted. This catches well-intentioned verification templates, because the instinctive way to confirm someone's identity is to ask for the whole number, which is precisely what the rule exists to prevent.
Abusive or threatening content is its own category, and it catches wording a business may not recognise as threatening. A payment reminder that warns of legal action or implies a defaulter will be named publicly falls here even when the underlying debt is entirely real. Softening the punctuation does not fix this class of rejection; the substance of the message has to change.
Category fit, and the wording that lets people stop
Every template is submitted under a category, and a mismatch between the declared category and the content is recorded as its own distinct rejection reason. This is not always an attempt to game the system. A business can sincerely believe a message is transactional while the review reads it as promotional, usually because a genuinely useful confirmation has an offer bolted onto the end. An order confirmation that closes with a discount code on the next purchase is a marketing message wearing a utility label, and the categorisation check is built to notice that.
The fix is to choose the category that honestly matches the message's purpose, not the one with the lighter consent requirement. Splitting the message in two — a clean confirmation as utility, the offer as a separate marketing template sent to people who opted in to marketing — is usually the shape that both passes review and behaves better in practice.
Marketing messages carry the additional expectation that recipients can stop them easily. Meta's policy requires businesses to honour opt-out requests, and giving people a plain way to say stop is both the compliant draft and the one that protects the account, since a person who cannot find a way out reaches for the block button instead. Authentication templates are the tightest category: no URLs, no media, no emojis, and a firm character limit on any parameter.
Read the rejection reason instead of guessing at it
Meta reports the specific rejection reason, and it is worth finding rather than inferring. The notification appears in Business Support Home under the relevant WhatsApp Business Account's rejected templates, and it is also sent by email, so a business watching only one of those two channels can miss the reason entirely and end up resubmitting blind. For a rejection based on duplication, the notice names the existing template that matches, which is often the fastest route to realising a near-identical template already exists and simply needs editing.
What to do next follows directly from the stated reason. A structural fault is corrected by editing the template's format and resubmitting, which starts a fresh review. A policy or content fault requires rewriting the substance. A categorisation mismatch is fixed either by rewriting the content so it genuinely is what it claimed, or by resubmitting under the category it actually belongs to.
If a business genuinely believes a rejection was wrong, an appeal is available, but an appeal is reviewed as a fresh judgement rather than an automatic reversal, and it is a poor substitute for fixing a fault that is real. Approval is also not permanent: a template's quality status can degrade later, and sustained negative feedback can see it paused or disabled well after it first passed.
A pre-submission pass that catches most of it
Most rejections are avoidable with a short, boring check before submitting. Read the template once for structure only: are the placeholders numbered sequentially from one, does the message start and end with real text, and does every variable sit inside a sentence that would still make sense if you read the placeholder aloud as a description of what goes there. Read it a second time for claims: is every price, fee and promise real and current, and is there any request for a full card, account or identification number. Read it a third time for category: if you had to defend the declared category to someone who only sees the text, could you.
The habit that matters most is timing. Submit templates days before a campaign needs them, not on the morning it launches. Review takes time that neither the business nor any platform sitting on top of the API can shorten, so a rejection discovered with no runway left is a missed send date rather than an inconvenience.
A template built for reuse repays this care many times over. A confirmation template approved once gets sent for every order afterwards, so an hour spent getting the structure right is amortised across every future send rather than spent on a single message.
Common questions
My template reads perfectly well. Why was it rejected?
Most likely for structure rather than wording. Check whether the placeholders are numbered sequentially from one with no gaps, whether the message starts or ends with a bare variable, and whether a short message is carrying so many placeholders that little fixed text remains. All three read fine to a person and fail the format check. Look up the stated reason in Business Support Home or the notification email before rewriting anything.
Can I put a discount code in my order confirmation template?
You can, but it stops being a utility message. A confirmation with a promotional offer attached is treated as marketing, and submitting it under utility is a categorisation mismatch. The cleaner approach is two templates: a confirmation that only confirms, sent as utility, and a separate marketing template with the offer, sent only to people who have opted in to marketing.
How soon can I resubmit after fixing a rejection?
You can edit and resubmit straight away, which starts a fresh review cycle. There is no stated cooldown on resubmission itself. What you cannot shorten is the review time, so fix the specific reason given rather than making a speculative change and resubmitting repeatedly in the hope that a different reviewer sees it differently.
Once a template is approved, is it approved for good?
No. A template's quality status can fall if recipients react badly or stop engaging, and sustained negative signals can lead to it being paused or disabled long after initial approval. A template that has been sending happily for months can still degrade, so its status is worth checking periodically rather than treating approval as a finished task.