A business can't just send arbitrary free text to a customer who hasn't messaged first — it has to be an approved template. What that means in practice, the rules that actually get templates rejected, and how to write ones that pass review quickly.
4 min read
Outside of an active customer-initiated conversation (covered in a later lesson), a business can't just send any text it wants to a phone number — that would be indistinguishable from spam. Instead, a business defines a template: a fixed message shape with named variable slots, submits it to Meta for review, and once approved, can send it filled in with real data as many times as needed.
Template (submitted once, approved once):
"Hi {{1}}, your appointment on {{2}} at {{3}} is confirmed."
Actual send (as many times as needed, once approved):
"Hi Sara, your appointment on Tuesday at 3pm is confirmed."
"Hi Omar, your appointment on Friday at 11am is confirmed."
The template's shape is reviewed once; each individual send just fills in the blanks.
Every template is submitted under one of the three categories from the first lesson in this domain — Utility, Marketing, or Authentication — and Meta reviews the actual wording against that declared category:
A template declared Utility but that actually reads as promotional ("check out our new services!") risks rejection at review, or worse, risks the sending number's quality standing if it slips through and is later flagged.
"{{1}}, your order shipped" gets rejected outright — a template needs literal text anchoring both ends: "Hi {{1}}, your order shipped." This is one of the most common first-submission mistakes, purely mechanical to avoid once known.{{1}}, with no gaps. A body that jumps straight from {{1}} to {{3}} — skipping {{2}} because, say, a patient-name variable genuinely isn't used in that particular message's wording — gets rejected, the same family of issue as the leading/trailing rule. If a variable truly isn't needed in the text, drop it from the send entirely rather than skipping its number.{
"messaging_product": "whatsapp",
"to": "15551234567",
"type": "template",
"template": {
"name": "appointment_confirmation",
"language": { "code": "en" },
"components": [
{
"type": "body",
"parameters": [
{ "type": "text", "text": "Sara" },
{ "type": "text", "text": "Tuesday" },
{ "type": "text", "text": "3pm" }
]
}
]
}
}The template name must exactly match what was approved in WhatsApp Manager — a typo here doesn't produce a helpful error pointing at the mismatch, it just fails to send.
Utility-category templates are typically approved within minutes; Marketing and Authentication can take longer and are reviewed more strictly. The practical implication: submit templates early, in parallel with backend build work, rather than the day before a launch while assuming "usually fast" is a guarantee. If a template is rejected, Meta generally states a reason — fix the specific issue named and resubmit; it isn't a one-shot process.
WhatsApp Manager ships a gallery of pre-built template examples (categories like "Appointment reminder," "Order confirmation," many with buttons already configured). Two honest uses for it:
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. A template body is written as: "{{1}}, your order has shipped!" What happens when this is submitted?
2. A business wants the same appointment-reminder message available in both Arabic and English. How is this actually set up?
3. A template is submitted as Utility category, but its actual wording is promotional ("Check out our new summer collection!"). What's the risk?
4. A developer copies a template directly from Meta's Template Library gallery, unmodified, and tries to send it with real customer data. What's wrong with this approach?
5. A template body reads: "Hi {{1}}, your order from {{3}} has shipped." — deliberately skipping {{2}} because that variable isn't needed in this wording. What happens?
WhatsApp & Meta Platform Integrations