WhatsApp Business templates: get approval from Meta

A WhatsApp Business templates is a message with a fixed and variable structure that Meta approves before use. It only serves one purpose, but decisive: to contact someone outside the 24-hour window, that is, when that person hasn't written to you recently.

This makes it the obligated piece of any automation based on dates — reminders, instructions, reminders, confirmations. No template approved, no auto message. It is also the part of the project that is least dependent on you: approval has its own timing and a poorly written template goes back.

Here we collect the practical rules that emerged by building five types of messages for six languages in the WhatsApp agent case study for short rentals, made for Rial Estate.

How a template is made

A template has a simple and rigid structure.

1. Header (optional). It can be a line of text, or a media: image, video or document. In the project of short rentals the header carries the PDF of the instructions.
2. Body (mandatory). The text of the message, with numbered variables you fill at the time of sending: name, date, amount.
3. Footer (optional). A short line, typically for a note or reference.
4. Buttons (optional). Quick actions such as "confirmation" or an external link.

The template must be stated in one category, and this choice is the most delicate of the whole process.

Categories: Making them wrong is the first cause of rejection

The rule that matters: if in the text there is an invitation to buy, it is marketing, although the rest of the message is of service. Placing a promotional phrase inside a template declared "utility" is the fastest way to get rejected, and also the most understandable from Meta's point of view.

The practical rules for moving on to the first revision

They are few and they respect each other easily, once you know them.

• The text must be understandable on its own. Who revises does not know your business: must understand from the message to whom it is directed and why.
• No opening or closing variables. A message that starts or ends with a placeholder is read as potentially empty. Always put fixed text around it.
• Variables must be numbered in order and use all. A skipped number is a format error.
• No variable can remain empty upon sending. If a data may be missing, predict a sensible fallback value before calling the API.
• Avoid too generic text. "Hello {{1}}, here is the information" provides no context and is often rejected.
• Consistency between Header and Body. If the header is a document, the body must explain what it contains.

A good written example and a bad written one

A body that passes without problems has this form: "Hello {{1}}, your reservation at {{2}} is confirmed from {{3}} to {{4}}. You will receive arrival instructions in the next few days." The context is clear, the variables are surrounded by text, and the reader understands what it is.

A body that is rejected resembles this: "{{1}}, here is your link: {{2}}". Opens with a variable, closes with a variable, and explains neither who writes nor why.

The Language Problem

Each language is a separate template. Five message types for six languages make thirty templates, each with its own revision.

This has two practical consequences that should be addressed at the project stage and not close to launch.

The first is by time: approvals do not all come together, and until a language is approved guests who correspond to it receive nothing.

The second is by robustness: needs defined behavior for when the language is missing. In the project of short rents English acts as a fallback. Without an explicit fallback, a recipient with an unapproved language produces an error — and, if the queue is not isolated per recipient, that error also stops subsequent submissions. It is exactly one of the incidents told in Six errors paid in the field.

The choice of the language to be assigned to each recipient is a problem in itself, treated in Multi-language automatic messages.

Manage thirty templates without losing your mind

With five messages for six languages you get to thirty objects to govern. It is the point where an ordered project is distinguished from one that will become unmanageable in six months.

Three tricks solve almost everything.

• A rigid naming convention. The template name must say message type and language in a predictable way, so that the stream can compose it itself instead of having a handwritten list to update.
• Only one point where it is written which languages exist. If the list is duplicated in the stream and documentation, sooner or later they diverge.
• A Revision Log. When a template is modified and sent back to review, you need to know when the new version is active: without it, when something changes in messages received from customers, nobody knows why.

Template maintenance is recurring, not one-off work. Whenever an internal procedure changes —a time, an access rule, a reference.you have to figure out which templates contain it and send them back to review. It is the practical reason why it is best to transform into a variable everything that has a concrete probability of changing.

Testing before going into production

An approved template is not a working template. The approval says Meta accepts that text, not that your stream fills it properly.

The tests that are worth doing, all on a number of tests and never on real customers:

1. Sending with all variables full. Check that the order of placeholders matches what you expect: it is easy to reverse two values and notice only from the received message.
2. Sending with an empty variable. It must fail in a predictable way, not produce a message with a hole.
3. I send in every language. Translations can move placeholders to positions that Italian did not foresee.
4. Sending to an unapproved language. It is used to verify that the fallback works and that the error does not block the queue.

The last test is the one that hardly anyone does, and it is the one that saved us from repeating an incident already seen — told in Six errors paid in the field.

Practical examples

A study that sends reminders. A utility category template, body with name, date and time, no business invitation. It passes without difficulty because the context is obvious and the message is clearly linked to an appointment already made.

An e-commerce that alerts you to shipping. Utility, with the tracking code as a variable and a button that opens the courier page. If in the same message you add "and with the code DISCOUNT10 you have 10% on the next order", the template becomes marketing and must be declared as such.

A multilingual accommodation facility. The same welcome message in six versions. The practical advice: get the two languages that cover most customers approved first, so you can leave, and add the others as you go. A similar project for the travel industry is described in AI for travel agencies.

Mistakes to Avoid

Finding out the approval times when the project is finished. It's the most common scheduling error. Templates should be submitted for review as soon as the text is decided, in parallel to the development, not after.

Promotional text in a service template. I refuse almost certainly, and a revision lost.

No fall back when the tongue is missing. It produces failures in production, often right on the least frequent recipients — so difficult to notice in tests.

Templates too rigid. If the fixed text contains something that changes every season (a time, an internal rule), each change requires a new revision. It is better to turn it into variable from the beginning.

Not keeping the list. With thirty active templates you need a place where it is written which template corresponds to which message in which language, otherwise maintenance becomes an archaeological work.

How to apply it in the company

1. List messages that you have to be able to send out cold. They are the ones that will become templates.
2. Assign the right category to each, looking at the content and not the intention.
3. Write the lyrics in Italian, then translate them. Check that variables make sense in all languages: word order changes and a placeholder can end up in the opening.
4. Send to review soon, and in the meantime build the rest.
5. Define the fallback by missing language and wrong recipient before going into production.

The link to the rest of automation —where the data that fills the variables comes from —is described in Integrating management software and in automation with n8n.

Conclusion

The WhatsApp Business templates are the least technical and most underrated part of an automatic messaging project. They don't require development skills: they require you to write well, to choose the category honestly, and to count a time you don't control.

The two rules that solve most rejections: make the message explain itself to those who don't know your business, and never start or finish a template with a variable.

AI becomes useful when it enters processes. Giallo Studio helps SMEs and teams to build concrete, measurable and sustainable automations. The complete operation of the channel is explained in WhatsApp Cloud API.