Meta Deprecated Three Message Tags: Why Your Messenger Integration Now Returns Error Code 100
CONFIRMED_EVENT_UPDATE, ACCOUNT_UPDATE and POST_PURCHASE_UPDATE are gone. Meta published two different cut-off dates for the same change, the reference page still lists the tags as if nothing happened, and the replacement is a fork rather than a swap.
This is not a rate limit and it is not an outage. Three of the message tags that let a business reach a customer after the 24-hour standard messaging window closed have been removed from the Messenger Send API, and requests that still carry them are rejected. If your product sends order updates, appointment reminders or account notices through Messenger, the affected code path is the one your customers notice first — and it fails at the API layer, silently, where nobody is looking.
What Meta actually removed
Verbatim, from the Messenger Platform Send a Message documentation: “Effective April 27th, 2026, all API requests containing the Message Tags CONFIRMED_EVENT_UPDATE, ACCOUNT_UPDATE, and POST_PURCHASE_UPDATE will receive error code 100.”
Error code 100 is Meta’s generic invalid-parameter error. It is the same code returned for a malformed field name or an unsupported value, so nothing in the response tells you that a policy changed rather than your payload. Teams reading their logs see an argument error and go looking for a bug in their own request builder.
Meta published two different dates for the same deprecation
⚠ The Send API reference carries a different notice: “Effective February 10th, 2026, Message Tag related to CONFIRMED_EVENT_UPDATE, ACCOUNT_UPDATE, and POST_PURCHASE_UPDATE will no longer be available.” Two official Meta pages, two dates, more than two months apart, for the same three tags — and the earlier notice does not mention error code 100 at all.
There is a second trap on the same page. The Send API reference still lists all five tags in the tag enum, each with its description and its allowed-usage table, and carries no deprecation marker on the individual entries. A developer who opens the reference today, reads the enum and builds against it will ship code that cannot work.
What survives, and what does not
| Tag | Current state | Instagram Messaging API |
|---|---|---|
| ACCOUNT_UPDATE | Removed — returns error code 100 | Was not available |
| CONFIRMED_EVENT_UPDATE | Removed — returns error code 100 | Was not available |
| POST_PURCHASE_UPDATE | Removed — returns error code 100 | Was not available |
| CUSTOMER_FEEDBACK | Still documented | Not available |
| HUMAN_AGENT | Still documented | Required for Instagram Messaging API |
Two tags are left standing and neither is a drop-in replacement. HUMAN_AGENT allows “a human agent to respond to the person’s message” within 7 days, and its allowed-usage table names automated messages as a disallowed use. CUSTOMER_FEEDBACK “can only be used with the Customer Feedback Template. Use in any other form is prohibited and will fail.” Rerouting transactional traffic through either one is a policy violation dressed up as a workaround.
The replacement is a fork, not a swap
Utility Messages
Meta describes these as “a pre-approved template message that include orders, account updates, and appointments” with personalised fields and call-to-action buttons. Pre-approved is the operative word: a template now has to be authored, submitted and accepted before it can send anything.
Marketing Messages
A consent-based channel. You “ask a person for permission to send multiple, marketing messages after the standard messaging window has ended.” It depends on an opt-in you almost certainly never collected, and it is built for promotional content, not receipts.
Neither is automatic
Meta publishes no migration script and no mapping table from an old tag to a new template. Every notification your product sends has to be reclassified by hand, and that classification decides both the approval path and the cost.
Where this quietly breaks a multi-tenant product
The failure never reaches your UI
Error code 100 comes back to your server, not to the end user. Nobody files a ticket until a customer mentions that a shipping notification never arrived, by which point the delivery gap may be weeks deep.
Templates are per-use-case, not per-tenant
A platform sending on behalf of hundreds of client Pages has to decide whose templates these are, who submits them, and what happens when one client’s wording is refused while the rest pass.
Reclassification is a policy judgement, not a data migration
Meta states that Message Tags “may not be used to send promotional content, including but not limited to: deals, offers, coupons, and discounts.” The line between a utility notice and a marketing message decides which channel you land in — and getting it wrong is what draws enforcement.
Enforcement lands at account level
“Use of Message Tags outside the approved use cases may result in restrictions on the Page or Instagram account’s ability to send messages.” On a shared app, a restriction does not politely stay inside the tenant that caused it.
Human Agent carries its own review gate
Meta: “Human Agent permission is not available in standard access or development mode. You will need to complete the app review process before you can leverage the human agent tag.” If the fallback plan was to lean on it, that is an App Review submission with a demonstration, before a single message sends.
What this actually costs
The engineering change is small. The expensive parts are the ones that are not code: deciding which of your notifications are utility and which are marketing, writing templates that clear review the first time, and putting a submission in front of Meta that does not come back refused. That classification and submission work is what I handle — see the messaging window and message tags breakdown, the Messenger bot App Review guide, a 15-permission Meta approval case study, and the App Review rejection fix service if a submission has already come back rejected.
Educational article reflecting Meta’s publicly documented Messenger Platform behaviour as of August 2026, quoted from official developer documentation. Platform rules change without notice — always confirm against current official documentation before making product decisions. I am not affiliated with, endorsed by, or partnered with Meta. This is review preparation, policy-aligned guidance and technical implementation support; no specific outcome or timeline can be assured.