Message templates: why every outbound message needs Meta's approval first

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.

Intermediate

4 min read

Why templates exist at all

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.

Category is chosen at submission time, and it's enforced

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:

  • Utility — transactional (confirmations, reminders, alerts). Fastest approval, cheapest per-message cost. This is what most first integrations need.
  • Marketing — promotional. Stricter review, materially higher cost, and requires the recipient to have explicitly opted in.
  • Authentication — one-time codes, with Meta controlling the surrounding wording.

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.

Rules that cause real, avoidable rejections

  • Never start or end a template body with a variable. "{{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.
  • Variables must be sequential starting at {{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.
  • One template object per language. Templates aren't automatically multi-language — a business supporting two languages submits two separate template objects (same logical message, each with its own name), not one template with mixed-language content.
  • Templates are scoped to the WABA they're submitted under (covered in this domain's hierarchy lesson) — submitting under a test/sandbox WABA and expecting it to carry over to a production WABA doesn't work.
  • Category must match content. A Marketing-flavored message declared as Utility is a rejection risk at review time and a quality-rating risk if it isn't caught there.

What a template looks like on the sending side

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

Approval turnaround — plan around it, don't assume it

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.

Meta's own Template Library — useful, but not a shortcut

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:

  • Inspiration for wording and structure that's known to review well, since these are Meta's own pre-approved patterns.
  • Not a substitute for a business's own template — the library's generic wording won't have a specific product's actual variables (a patient's name, a specific service, a specific business name) wired in. Still worth writing a business's own template, informed by the library's patterns rather than copied wholesale.

Further reading

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?