WhatsApp Cloud API error codes, explained one by one

In two places. Synchronous errors are returned in the HTTP response body as an error object with code, message, error_data.details and fbtrace_id. Asynchronous errors, such as delivery failures detected after the send was accepted, arrive in the statuses webhook with status failed and an errors array. Handle both, because a 200 response does not guarantee delivery.

On the integer code. Meta's documentation recommends building error handling around code and error_data.details rather than HTTP status codes or the deprecated error_subcode. The message field combines the code with a short title that Meta has said will eventually be deprecated, so do not parse it for logic.

131047, Re-engagement message. It means more than 24 hours have passed since the customer last messaged you, so only an approved template may be sent. It is not a bug; it is the customer service window rule. Track the last inbound timestamp per contact and fall back to a template when the window is closed.

Transient platform errors (1, 2, 131000, 131016, 133004), the throughput limit 130429 and pair limit 131056 with backoff, and maintenance mode 131057 after a short wait. Do not retry 131026, 131047, 131049, 131050, 130403 or any 132xxx template error without changing something first; they will fail identically.

130429 is throughput: you sent faster than your number's messages-per-second allowance, so pace and retry. 131048 is a quality-based restriction caused by blocks and spam reports; retrying does nothing and you must fix audience and content. 131056 is the pair limit for one recipient, roughly one message every six seconds to the same user.

The temporary access token shown in the App Dashboard expires after 24 hours. Generate a permanent token from a System User in Business Settings with whatsapp_business_messaging and whatsapp_business_management, store it in a secrets manager, and verify in the Access Token Debugger that it never expires.

Because 132xxx errors are about the template, not the recipient. 132000 means your parameter count per component does not match; 132001 means the name or language does not match an approved template on that WABA; 132012 means a value has the wrong format; 132015 and 132016 mean the template was paused or disabled for low quality.

It is the trace identifier for that specific API call. Meta Direct Support uses it to locate the request internally and cannot investigate without it. It is not recoverable after the fact, so log the entire error object, including fbtrace_id and error_data.details, rather than only the numeric code.

The prefix tells you which subsystem refused you. Short Graph API codes (0 to 368) are authentication, permissions, and malformed requests. 130xxx are throttling and account-level restrictions. 131xxx concern delivering this message to this recipient, from window failures (131047) to undeliverable numbers (131026). 132xxx are about the template itself, so they fail identically for every recipient. 133xxx are phone number registration, and 135000 is an unclassified parameter problem. Triage the family first, then the specific code.

Because many failures are asynchronous. The API returns 200 with a message ID, then delivery fails, and the only record is a statuses webhook with status failed. If your webhook endpoint is unsubscribed, rejecting payloads, or timing out, those failures vanish. Subscribe to the messages webhook field, log every statuses entry including its errors array, and work through /blog/webhook-not-firing-debugging-guide if events are not arriving at all.