On this page

A WhatsApp template variable is a {{n}} placeholder that gets replaced with real data at send time, but Meta enforces strict rules on how they can be numbered, placed and spaced before it will even review the template. This article covers those rules, plus how a variable actually resolves to data once the template is approved and used.
Variables: first 5 of 6 steps
- 1Number variables sequentially from {{1}}
- 2Never open or close the message on
- 3Keep variables apart from each other
- 4Surround variables with enough fixed text
- 5Give each one a realistic sample
Before you start
- Variables are written directly into the body, or a single one into a text header, while building or editing a template; there is no separate variables screen at this stage.
- Where a variable's value comes from at send time (a contact field, a fixed value, or a fallback) is set later, when the template is actually used in a broadcast, flow or automation, not while building the template itself.
- Every variable needs a sample value before submission regardless of where it will later be mapped from; see media headers and sample values for that requirement in detail.
Steps
- Number variables sequentially from {{1}}. Type
{{1}},{{2}},{{3}}and so on in the order they should appear, with no number skipped.{{1}}and{{3}}with no{{2}}anywhere in the template is rejected as a numbering gap.

Never open or close the message on a variable. "
{{1}}, your order has shipped" and "Your order has shipped,{{1}}" are both rejected. Add fixed text before the first variable and after the last one: "Hi{{1}}, your order has shipped."Keep variables apart from each other. "
{{1}}{{2}}" with nothing but a space between them is rejected as adjacent variables, since the rendered value reads as one run-on string a reviewer cannot verify. Separate them with real words: "{{1}}, your{{2}}is ready."Surround variables with enough fixed text. A body that is mostly placeholders with barely any wording between them reads as a data form rather than a message, and the validator flags this as low variable density. Aim for full sentences around each variable, not a template that is essentially a mail-merge field list.
Give each one a realistic sample. A sample like "Priya," "ORD-20891" or "2:30 PM" lets Meta's reviewer judge the sentence properly; a placeholder like "test" or "value1" does the opposite and is a common cause of rejection on its own.
Map each variable at send time. When a template is used in a broadcast, a flow node, a drip sequence or an automation rule, each variable is mapped to where its real value comes from: a contact field (name, phone, email), a custom field, a fixed static value, or a tracked link. Every source except static text requires a fallback value, used whenever the underlying field is empty, so a send can never fail with a parameter-count mismatch because a contact's field happened to be blank.
What you will see
The live phone preview substitutes your entered sample values as you build the template, so you can read the message the way a reviewer, and later a customer, actually will. Once the template is in use, wherever it is sent from shows its own mapping interface for choosing each variable's data source and fallback.
Settings and options
| Rule | Limit | Where enforced |
|---|---|---|
| Body variables | Up to 10, numbered sequentially from {{1}} | Pre-submission validator |
| Header variables | At most 1, text headers only | Pre-submission validator |
| Footer variables | None allowed | Pre-submission validator |
| Media header variables | None allowed | Pre-submission validator |
| Variable at start or end of body | Not allowed | Pre-submission validator |
| Adjacent variables | Not allowed | Pre-submission validator |
| Fixed text around variables | Roughly 20+ characters per variable recommended | Pre-submission validator (warning) |
| Fallback value at send time | Required for every non-static, non-tracked-link variable mapping | Broadcast, flow, sequence and automation-rule variable mapping |
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| "Variables can't be at the start of the template" | The body opens directly on {{1}} | Add a greeting or other fixed text before the first variable |
| "Variables can't be at the end of the template" | The body closes directly on the last variable | Add a closing sentence or fixed text after it |
| "Two variables sit next to each other" | Two {{n}} placeholders have nothing between them | Add a word or two of fixed text separating them |
| "Variable {{[n]}} is missing but {{[max]}} exists" | Variables skip a number, for example {{1}} and {{3}} with no {{2}} | Renumber so every integer up to the highest is used with none skipped |
| "Only [n] characters of fixed text around [m] variable(s)" | The body is mostly placeholders relative to its fixed wording | Rewrite as full sentences with the variables embedded naturally, rather than a list of fields |
| "Variable {{[n]}}: a fallback value is required" when mapping in a broadcast | A non-static variable mapping has no fallback set | Enter a fallback value used whenever the contact's field is empty |
Related reading
Variable rules are one part of the wider component structure a template follows; see headers, body, footer, buttons and carousel for the rest, and media headers and sample values for how header variables differ from body variables specifically.