WhatsApp Conversions API errors 2804066, 2804131 and 2804081: the fix for each.

Refused, one error at a time

We run an AI sales agent on the official WhatsApp Cloud API for a cash-on-delivery store. Buyers reach it through click-to-WhatsApp ads, and the order comes later in the chat. Each order should go back to Meta as a conversion event through the Conversions API, because those events are what give click-to-WhatsApp ads access to purchase optimization. At first, Meta accepted none of them.

Every fix brought the next error to the surface. The first was subcode 2804066: Meta refused the event names, Lead included. Then came 2804131, which stayed until the events went to the dataset linked to the WhatsApp Business Account, carrying the WhatsApp Business Account ID in place of the Page ID. With that, Meta accepted the event for a real customer order. Two days later, an OrderCreated event without a currency came back with 2804081. The fix is a currency code on every order event.

We turned all of it into whatsapp-conversions-api, a free, open-source library and command-line tool. It builds the payload, checks every event for all three mistakes before anything is sent, sends each order once and explains Meta's error codes in plain words.

What each error code means

These four responses came from the live API. Here is what each one means and how to fix it.

We could not find 2804066, 2804131 or 2804081 in Meta's public docs.

The other codes you can hit when sending events come from Meta's Graph API and Marketing API error references:

• 100, invalid parameter: read the subcode and Meta's message in full, since the message can name the values Meta accepts.
• 102 or 190, an invalid or expired access token: get a new token.
• 3, 10 or 200–299, a missing permission: the token needs whatsapp_business_management and whatsapp_business_manage_events.
• 1, 2, 4, 17, 341 or 368, a temporary problem, throttling or a temporary block: wait, then send again.

The event names Meta accepts

Meta accepts a short list of event names for business messaging, and Lead is not on it. Here is what the live API did when we tried names one by one, and what Meta's docs add:

For a lead, send LeadSubmitted, then QualifiedLead once the lead is qualified. For a cancellation, send OrderCanceled. And give every order event a currency: Meta's docs require one on purchases, and the live API also refused an OrderCreated event without one.

Where the dataset ID, WABA ID and ctwa_clid come from

Three values tie an event to your ad and to your WhatsApp business, and the token that sends it needs two permissions. Here is where each one comes from.

• Dataset ID. POST /<waba-id>/dataset on the Graph API returns the dataset linked to your WhatsApp Business Account, and creates one if there is none. It is not your website pixel: events sent to ours came back with 2804131. Meta's docs also allow linking an existing dataset, one per Page.
• WhatsApp Business Account ID, or WABA ID. The account your WhatsApp number belongs to, sent as user_data.whatsapp_business_account_id. Not the Page ID, and not the phone number ID.
• Ad click ID, the ctwa_clid. It arrives in the WhatsApp messages webhook at entry[].changes[].value.messages[].referral.ctwa_clid, on the message that came from the ad. Save it with the conversation, since the order comes later in the chat. Meta leaves it out for ads shown in WhatsApp Status, and a conversation that did not start from an ad has none.
• Access token. It needs the whatsapp_business_management and whatsapp_business_manage_events permissions.

A 200 is not a receipt

Meta also answers 200 OK when it took no event at all. The response then says events_received: 0, with no error attached. Read events_received on every response: the tool treats a 200 with nothing received as a failure, records nothing, and says so.

Meta rejects the whole request when one event in it is invalid, so one bad event costs all of them. That is why the checks run before anything is sent: an event name Meta refuses, a Page ID or dataset ID where the WhatsApp Business Account ID belongs, a missing or hashed click ID, a Purchase or OrderCreated event without a currency, a value that is not a number, and an event_time in milliseconds, in the future or more than 7 days old.

To watch events arrive, send one with a test event code from the Test Events tab in Events Manager. Meta's docs say test events still count for targeting and measurement, so the tool records them in its ledger like any other event.

Count each order once

Our agent had assumed that Meta deduplicates within 48 hours, the window Meta documents for a pixel event paired with a server event. The business messaging docs go further: Meta does not deduplicate these events at all. Counting each order once is up to the sender.

The tool gives every event a stable ID made of the order ID and the event name, such as 1042:OrderCreated, and keeps a ledger with no time limit. An ID is marked before the request leaves and kept once Meta confirms, so a retry, a crash or a replay a week later never counts an order twice. With several workers, keep the same rule in your database: a unique key on the event ID, written before the request leaves.

The code, the checks and the error explanations are free on GitHub, MIT licensed and without dependencies: whatsapp-conversions-api. We build WhatsApp sales agents like this one for businesses: see our WhatsApp AI chatbot page.