MM Lite Was Renamed. The Payload Still Says marketing_lite

What is the Marketing Messages API for WhatsApp, and what happened to MM Lite?

It is the same product at the same endpoint under a new name. Meta's current documentation calls it the Marketing Messages API for WhatsApp, abbreviated "MM API for WhatsApp":

"MM API for WhatsApp is an API for sending marketing messages on WhatsApp that optimizes delivery to reach more of the people most likely to find your messages relevant." (Meta - Marketing Messages API for WhatsApp)

A couple of things around the edges changed with it. Partners no longer receive access to ad accounts and the ad_account_linked webhook event is retired, and a max-price-per-delivery control is documented as arriving in 2026. Both are covered further down.

What did not change is the wire format. Meta's own Get Started page states that when a message goes out through this API, the status webhook carries category and conversation.origin.type set to marketing_lite — the old name, as a literal string, in the payload your server parses.

That gap is where the integration work actually is. Of the vendor pages ranking for this product — AiSensy, Infobip, CleverTap, Gupshup, 360dialog, Wati and a dozen more — the ones checked in September 2026 announce the rename and stop there. None mentions that a reporting query, a quota counter or a billing reconciliation that matches on the string marketing will match none of these sends, will raise no exception, and will simply report a smaller number than the truth for as long as nobody notices.

• What is the Marketing Messages API for WhatsApp, and what happened to MM Lite?
• Why does the payload still say marketing_lite after the rename?
• What exactly breaks when category comes back as marketing_lite?
• What do errors 134100, 134101 and 134102 actually mean?
• Why is 134102 served as an HTTP 500 when it is not a server fault?
• Why does a template created minutes ago fail with 134101?
• Where does the "9% more messages" figure actually come from?
• Which countries lose delivery optimisation and reporting?
• Does it save money, and what does it actually give you?
• Who has to accept the Terms of Service, and can a provider do it for you?
• Should you move your marketing sends to this endpoint at all?

Why does the payload still say marketing_lite after the rename?

Meta does not explain why, and this article will not guess. What is checkable is where the old name survives, and it survives in more than one place. The first is the status webhook, where Meta's Get Started page is explicit:

"When a message is sent via MM API for WhatsApp, the webhook payload will have category and conversation.origin.type set to marketing_lite." (Meta - Get started)

The second is onboarding. When someone accepts the Terms of Service, Meta fires an account_update webhook whose event value is MM_LITE_TERMS_SIGNED. The third is the documentation URL itself, where the marketing-messages-lite-api path still resolves.

So there are two vocabularies in play at once, and they are not interchangeable. Prose says "Marketing Messages API". Code must say marketing_lite. A page that reports the rename without reporting that the payload kept the old name has told you half the fact, and it is the half that reaches production.

Checked against Meta's documentation on 11 September 2026.

What exactly breaks when category comes back as marketing_lite?

Nothing breaks loudly. That is the problem. A category your code has never seen does not throw; it fails an if and falls through to whatever your else branch does, which in most reporting code is nothing at all.

A status webhook for one of these sends looks like this in the part that matters:

"pricing": { "category": "marketing_lite" },
"conversation": { "origin": { "type": "marketing_lite" } }

Here is what that touches in a typical stack.

Every one of those is a silent undercount rather than an error, and the direction is consistent: your own numbers come in below Meta's. That is the worst possible direction for a discrepancy, because the number that looks wrong is Meta's invoice, and the natural first response is to dispute it. Reading what Meta actually charged you starts from the assumption that both sides are counting the same rows, and here they are not.

The fix is one line per call site. The only hard part is finding all of them.

What do errors 134100, 134101 and 134102 actually mean?

Meta lists eight codes under its "Marketing Messages API for WhatsApp error codes" heading (Meta - WhatsApp Cloud API error codes): 100, 131009, 131055, 132018, 134100, 134101, 134102 and 1752041. Only the three in the 1341xx block are specific to this endpoint, and they are the ones people arrive searching for. The other five are familiar Cloud API codes doing familiar jobs, and a retry classifier written for this endpoint has to handle all eight.

Two of those repay a second look before the 1341xx block. 131055 carries the detail text "Only marketing template messages are supported", which is the same refusal as 134100 wearing a different number, so a classifier keyed on 134100 alone will miss half the cases. And 1752041 is an onboarding-time code, not a send-time one: Meta's detail text says it "is thrown when a client has already been invited to onboard by any partner" — by any partner, so a customer another provider has already invited produces it against you.

134100 fires when you point a non-marketing template at a marketing-only endpoint. Meta's own detail text is one sentence:

"You're only able to send marketing messages on this API." (Meta - WhatsApp Cloud API error codes)

This is worth knowing about specifically because template categories are not fixed. Meta can reassign a template's category after approval, and a utility template that becomes a marketing template, or the reverse, changes which endpoint will accept it — see why Meta changes a utility template to marketing for how that reassignment happens and what notice you get.

134101 is the timing race, covered in its own section below.

134102 usually means the account was never onboarded, but Meta's remedy text stops short of saying only that:

"Please check your eligibility status to ensure you are onboarded or contact Meta's customer support." (Meta - WhatsApp Cloud API error codes)

The second clause points somewhere other than your own configuration, so treat eligibility as the first thing to check rather than the settled diagnosis. What holds either way is that no amount of retrying clears it.

Checked against Meta's documentation on 11 September 2026.

Why is 134102 served as an HTTP 500 when it is not a server fault?

Because that is what Meta's error page lists against it. In the HTTP Status column, 134102 reads 500 Internal Server Error, while 134100 and 134101 both read 400 Bad Request.

That is inverted at both ends. A send pipeline's retry classifier almost always keys on the HTTP status band first: 4xx is the caller's fault and permanent, 5xx is the server's fault and transient, retry with backoff. Under that rule, the one fault on this endpoint that no retry can clear is the one that gets retried forever, and the one genuinely transient fault on the endpoint — a template that needs a few minutes to finish syncing — arrives as a 400 and gets abandoned on the first attempt.

The practical rule for anyone writing against /marketing_messages: classify on the numeric error code in the body, not on the HTTP status band. Hard-code 134102 as permanent despite its 500, and treat 134101 as worth retrying despite its 400. A queue worker that does not do this will burn its retry budget on a fault no amount of retrying can clear, and the symptom — repeated identical failures seconds apart against one number — looks like an outage rather than a missing Terms of Service acceptance.

Checked against Meta's documentation on 11 September 2026.

Why does a template created minutes ago fail with 134101?

Because a freshly created template is not immediately usable on this endpoint. Meta's error reference gives the window:

"When you send a message from a template, the template syncing process can take up to 10 minutes to complete." (Meta - WhatsApp Cloud API error codes)

Ten minutes is a long time in a create-then-blast workflow, and the failure shape is specific enough to be worth naming. A campaign dispatcher that sends in chunks — a chunk, then re-queue, then the next chunk — launched immediately after a template was approved will fail its first chunk with 134101 and succeed on every chunk after the sync completes. Partial delivery, no obvious cause, and the second launch attempt works fine because the ten minutes elapsed while somebody was reading the logs.

This one is genuinely retryable, which makes it the exception on this endpoint rather than the rule. Retry it with a delay measured in minutes, not the sub-second backoff a 400 would normally get, and put a deliberate gap between creating a template and scheduling anything against it.

WabaCRM's own dispatcher sends one chunk and re-queues itself, which is what makes pause and cancel possible mid-campaign — and is also precisely the shape that makes a ten-minute sync window visible as a partial failure rather than a total one.

Where does the "9% more messages" figure actually come from?

From one A/B test, in one country, over one month, scoped to one kind of message. Meta's features page states the benefit like this:

"Marketing Messages API for WhatsApp factors whether a message is high engagement into delivery decisions, delivering up to 9% more messages versus Cloud API" (Meta - Features, Marketing Messages API for WhatsApp)

and its own footnote scopes that claim tightly:

"The A/B test was conducted with approximately 12 million delivered marketing messages sent by advertisers in India from January 1, 2025 to January 31, 2025. It compared Marketing Messages API for WhatsApp optimized delivery to standard Cloud API delivery for high engagement messages only (specifically, more reads and clicks) and the analysis consisted of a t-test at 95% confidence." (Meta - Features, Marketing Messages API for WhatsApp)

Four qualifiers sit inside that: up to 9%, India only, January 2025 only, and high engagement messages only. It is an upper bound on a subset, not an expected uplift on your list.

There is one genuinely interesting consequence for an Indian sender, and it runs the opposite way to the usual regional story. India is not a market waiting for a feature to arrive here. India is the market Meta measured the feature in, and — as the next section shows — the six regions where these optimisations are switched off do not include it.

If a page quotes a figure larger than 9%, that figure is not Meta's. Meta publishes exactly one number for this, with exactly that footnote attached.

Which countries lose delivery optimisation and reporting?

This is the restriction buried at the bottom of Meta's Get Started page, and it is the one that quietly invalidates the main selling point for a large part of the world. Read the trigger carefully, because it is not a table of sender geography:

"Messages sent from a business phone number in these countries, or to a WhatsApp user in these countries, will not receive delivery optimizations." (Meta - Get started)

Either end of the message is enough. A sender outside these regions loses the optimisation and the metrics on every message aimed at somebody inside one of them.

Meta adds a second sentence about those countries that is easy to skim past and changes what the restriction means:

"Note that per-user marketing message template limits are also not active in these countries, so a lack of delivery optimizations will not have any effect on message delivery." (Meta - Get started)

Read carefully, that ties two things together. The optimisation is off in those markets, and so is the per-user marketing limit the optimisation works against. So a vendor pitch built on "this API stops you over-messaging a customer" describes a mechanism that is not running for a European or Japanese audience at all. The per-user marketing limit is one of several separate ceilings that people routinely conflate; what actually caps a WhatsApp broadcast separates them.

Two further geographic facts from the same page. Russia and Belarus were admitted from 20 June 2025 without delivery optimisations or click and conversion metrics. And the United States is not a valid destination for marketing messages at all:

"Starting April 1, 2025, marketing messages sent to WhatsApp users in the United States will not be delivered (error code 131049)." (Meta - Get started)

That is the same numeric code Meta uses for the per-user marketing limit, which means a single error number now carries two unrelated causes — see what error 131049 means before concluding a US non-delivery is a frequency problem.

Cuba, Iran, North Korea, Syria, Venezuela and three sanctioned regions of Ukraine cannot onboard to the API at all.

Checked against Meta's documentation on 11 September 2026.

Does it save money, and what does it actually give you?

It does not save money on its own. Meta's overview states the position directly:

"MM API for WhatsApp offers a similar technical schema and same billing model as Cloud API, and businesses can use existing phone numbers and MM templates." (Meta - Marketing Messages API for WhatsApp)

Same billing model. A marketing template delivered here costs what a marketing template costs. The only price control Meta documents is separate, and dated:

"Starting in 2026, businesses integrated into Marketing Messages API for WhatsApp can choose to set a max-price per marketing message delivery; when a max-price is set, Meta will charge that max-price or lower for delivery." (Meta - Pricing on the WhatsApp Business Platform)

What you do get, beyond the delivery optimisation quantified above, is a time-to-live control on each send. Meta's features page states that "TTL can range from 12 hours to 30 days." For a campaign with a genuine expiry — an event, a sale with an end date — that is a real capability, because it lets a message stop being attempted rather than arrive after it has stopped being true.

None of this changes who pays Meta. Under the Tech Provider model each business attaches its own payment method to its own WhatsApp Business Account and Meta bills them directly, so a platform on that tier cannot add a markup to any of these figures. The difference between the provider tiers decides whether anyone sits between you and Meta's published rate.

Who has to accept the Terms of Service, and can a provider do it for you?

Not the provider. Meta's onboarding page is specific about who the acceptance has to come from:

"You can instruct your business customers to have someone with full control to the business portfolio to accept the Terms of Service and onboard MM API for WhatsApp via WhatsApp Manager." (Meta - Onboard)

"Full control to the business portfolio" is a named permission level inside the customer's own organisation. A provider cannot hold it on their behalf, a support agent cannot click through it, and no amount of API access substitutes for it. In practice that makes onboarding a scheduling problem rather than a technical one: the person who can accept is usually not the person building the integration, and the send will keep returning 134102 until they do.

Eligibility is readable rather than guessable. Meta's onboarding documentation describes marketing_messages_onboarding_status on the WhatsApp Business Account, stating that eligible accounts have the field set to ELIGIBLE and that ONBOARDED means the account has already been onboarded. Read that field before debugging a send.

One retirement to note if you are a partner with existing code: Meta's onboarding page warns that

"Important: The ad_account_linked webhook event will no longer be fired since partners will not receive access to ad accounts." (Meta - Onboard)

An onboarding flow still waiting on that event is waiting for something that will not arrive, which is the same class of silent failure as the category string at the top of this article: no error, no log line, just a step that never completes.

Should you move your marketing sends to this endpoint at all?

The case for moving is real and narrow: a Meta-measured delivery uplift of up to 9% for high engagement messages, measured in India, plus a TTL control Cloud API does not offer. For an Indian sender messaging an Indian list, both apply in full and neither suppression does — but the suppressions follow the recipient too, so any slice of your audience in the EEA, UK, Japan, South Korea, Nigeria or South Africa gets neither the optimisation nor the click and conversion metrics.

The case against is integration cost, and it is entirely front-loaded. You are adding a second send path that is send-only and marketing-only:

"MM API for WhatsApp is a send-only API. It does not receive incoming messages from consumers." (Meta - Send Marketing Messages)

"Marketing Messages API for WhatsApp allows you to send marketing template messages only." (Meta - Send Marketing Messages)

So Cloud API stays, inbound stays, utility and authentication stay, and you have a second endpoint with eight error codes of its own, its own retry semantics, its own onboarding gate and a category string that does not match the one every existing report is written against.

The honest sequencing, then: make marketing_lite a first-class value in your reporting and reconciliation before you send a single message through the new endpoint, classify on the numeric error code rather than the HTTP status band, and get the Terms of Service accepted by someone who can actually accept them. Do those three things first and the switch is uneventful. Do them afterwards and the first sign of trouble is a monthly total that disagrees with Meta's invoice, weeks later, with no error anywhere to explain it.

Every Meta quotation on this page was read from Meta's own documentation on 11 September 2026. Meta changes that documentation without notice; the linked pages are authoritative and this one is not.