The message_template_status_update webhook

The statuses it carries

A template moves through a small set of states, and each change arrives here.

• Approved: the template can be sent from now on.
• Rejected: it cannot, and the reason accompanies the event.
• Paused: quality dropped far enough that Meta suspended it temporarily.
• Disabled: repeated pauses ended in a permanent stop, and a new template is required.

Why this removes polling

Because the alternative is asking repeatedly and guessing how often.\n\nWithout this event, an integration that creates a template has to poll get_template_status on some interval until the answer changes. Too often and it is wasteful; too rarely and a template sits approved for an hour before anything notices.\n\nWith it, the flow is submit and wait. Meta pushes the outcome, usually within minutes, and the integration reacts once. For an agency creating templates on behalf of clients that is the difference between a queue that drains itself and one somebody has to watch.

What to do on each outcome

Approved is the simple one: mark it sendable. The other three are where the value is.\n\nRejected carries a reason, which is worth surfacing verbatim rather than summarising, because the reason is usually specific enough to act on and a paraphrase loses that.\n\nPaused means the content produced bad reactions, and resending it after the pause lifts produces the same result. It is a prompt to edit rather than to wait.\n\nDisabled is final for that template. The only route forward is a new one with different content, and treating it as temporary leaves a send path broken indefinitely.

Common mistakes

• Polling for approval when this event reports it.
• Summarising a rejection reason instead of surfacing it. The specifics are what make it actionable.
• Waiting out a disabled template. That state is permanent and needs a new template.

Frequently asked questions

Keep reading