Skip to main content
When sending WhatsApp messages through Chirp, errors from Meta’s Cloud API are automatically mapped to Chirp’s standard error format. The original Meta error details are always preserved in the provider object so you have full context for debugging. For a general overview of the error format, see Errors.

Error Code Mapping

The following table shows how Meta error codes are mapped to Chirp error codes. When a Meta error does not have a corresponding Chirp code, the error response uses type and message only.
Entries marked with -- in the Chirp Code column use type and message only. These errors do not need a specific code because they do not require programmatic branching in your application.

Understanding Meta Error Responses

When a Meta error occurs, the Chirp API response includes the full provider details:
Meta error response

The Provider Object

Using fbtrace_id

The fbtrace_id is the most important field when you need to escalate an issue with Meta. It allows Meta’s support team to look up the exact request in their systems. When to save it:
  • Always log the fbtrace_id when a WhatsApp message fails
  • Store it alongside the message record in your database
  • Include it in any support tickets or bug reports
How to use it:
  1. Open a support case through Meta Business Help Center
  2. Include the fbtrace_id value in your report
  3. Meta can use this to trace the exact API call and diagnose the issue
Saving fbtrace_id

Common Scenarios

24-Hour Window Expired (131047)

WhatsApp Business API has a 24-hour messaging window. After a user messages you, you have 24 hours to respond with free-form messages. After the window closes, you must use an approved template message to re-initiate the conversation. What happens:
  1. A customer sends you a message at 10:00 AM
  2. You can send free-form messages until 10:00 AM the next day
  3. After 10:00 AM the next day, free-form messages fail with conversation_window_expired
  4. You must send a template message to re-open the conversation
How to handle it:
Handling expired conversation window
Track the last message timestamp from each customer so you can proactively switch to template messages before the window expires.

Account Restricted (368, 131031, 131042)

Account restrictions prevent you from sending messages. They can happen for several reasons: Steps to resolve:
  1. Log in to Meta Business Manager
  2. Check for any policy violation notices or account quality warnings
  3. Review the WhatsApp Business Policy
  4. If your account was restricted in error, submit an appeal through Business Manager
  5. For billing issues, update your payment method in account settings
Account restrictions affect all messages from your WhatsApp Business Account, not just individual phone numbers. Resolve them as quickly as possible to avoid service disruption.
Errors for these codes are automatically enriched with Meta’s own remediation text and the specific blocked entity via Health Status Enrichment. Read error.additional_info in the response to see exactly what needs to change.

Template Issues (132000, 132001, 132005, 132007, 132012)

Template errors occur when sending template messages. They fall into two categories: Template does not exist (132001, 132007):
  • The template name is misspelled
  • The template was not approved in the requested language
  • The template was rejected by Meta for policy violations
Template parameter problems (132000, 132012):
  • Wrong number of variables provided
  • Variables in the wrong format
  • Missing required header or button parameters
Troubleshooting steps:
  1. Verify the template exists in your dashboard or via the Templates API
  2. Check that the template status is “approved”
  3. Confirm the language code matches the approved template language
  4. Count the variables in your template body and verify you are providing the exact same number
  5. Check that variable types match (text, currency, date-time)
Template error handling

Health Status Enrichment

Some Meta errors — particularly account_restricted and display_name_not_approved — are returned with messages like “Account has been locked” or “Display name pending approval” that don’t tell you which account, which name, or what to do next. Chirp automatically calls Meta’s Health Status API when one of these errors occurs and attaches the specific blocked entity and Meta’s suggested remediation to the response.

Which errors are enriched

Other error codes are not enriched because their base messages already carry enough context to act on.

What gets added

When enrichment succeeds, the error body includes two extra fields:
  • error.additional_info — flat string[] of human-readable remediation hints. Ordered: BLOCKED entities’ possible_solution first, then LIMITED entities’ additional_info. Start here if you just need to show your operator “what to do”.
  • error.provider.health_status — the full entity tree from Meta’s Health Status API. Use this when you want to render a richer UI (per-entity status, SIP status, codes for programmatic branching).
Enriched account_restricted response

Entity types

The entities array in health_status is Meta’s tree of messaging-related nodes, ordered from most-specific to least-specific: Each entity has a can_send_message of AVAILABLE, LIMITED, or BLOCKED. When BLOCKED, the entity includes an errors[] array with Meta’s own error_code, error_description, and possible_solution. When LIMITED, it includes additional_info[].

Behavior on failed-message webhooks

Enrichment also fires for inbound messages.whatsapp.failed webhooks: when Meta reports a delivery failure with an enrichable code, Chirp fetches Health Status at ingest time and attaches the same provider.health_status + additional_info to the webhook body you receive. See the failed-message webhook example for the payload shape.

Handling enrichment in client code

Surface Meta's remediation text
Enrichment is best-effort. If Chirp’s call to Meta’s Health Status API fails (network issue, token problem, rate limit), you still get the base error — additional_info and provider.health_status will simply be absent. Never assume they exist; treat them as additive hints on top of error.code.
Health Status lookups are cached per Meta node ID (phone number, WABA, or template) for 60 seconds, shared across both API send-path errors and inbound failed-status webhooks. If many errors reference the same node within that window, Chirp makes one Graph API call, not many.