Error 131000 is the code Meta returns when it has nothing more specific to tell you. It is documented as "Something went wrong," with details reading "Message failed to send due to an unknown error," an HTTP status of 500 Internal Server Error, and a recommended action of trying again and opening a Direct Support ticket if the error persists (Meta for Developers, WhatsApp error codes reference, retrieved 2026-08-20).
The 500 matters here in a way it does not for error 3, where the same status is returned for what is really a configuration problem. Error 131000 is a genuine server-side failure, which means retrying is the correct first response rather than a waste of budget.
What trips teams up is the second half: knowing when a 131000 has stopped being transient and become a pattern worth escalating. This guide covers that boundary, the retry policy that fits, and what to gather before you open a ticket. For the wider failure surface, our WhatsApp Business API error codes reference indexes the rest.
What 131000 Is, and What It Is Not
The error_data.details field reads "Message failed to send due to an unknown error," which is honest rather than helpful. Meta's system encountered a failure it could not classify into a specific code.
Two related codes sit nearby and behave differently:
Code | Meta's description | HTTP | Retryable? |
|---|---|---|---|
131000 | "Something went wrong" | 500 | Yes, with backoff |
131016 | "Service unavailable" | 500 | Yes — check the platform status page first |
"Message Undeliverable" | 400 | Only for some causes | |
"Invalid parameter" | 400 | Never |
Meta documents 131016 as a service being temporarily unavailable, with a recommended action of checking the WhatsApp Business Platform Status page before trying again. That is the more informative sibling: if you are seeing volume of either code, check the status page before you debug anything of your own.
The distinction that matters operationally is the HTTP class. A 500 means the failure happened after your request was accepted and understood. A 400 means your request was the problem. Bucketing them into one retry policy is how a payload bug becomes a throttling incident.
A Retry Policy That Fits
Meta's guidance is to try again. Doing that well takes a little more structure than a loop.
Use exponential backoff with jitter. Double the wait after each attempt and add a random component, so that a fleet of clients that all failed at the same moment does not return at the same moment and recreate the spike. Full jitter — waiting a random duration between zero and the current ceiling — spreads recovery properly.
Cap the attempts. Three to five is reasonable. Beyond that you are not recovering from a transient condition, you are queueing, and the work belongs in a durable queue with an alert rather than in a retry loop.
Cap the total wait too. Roughly thirty seconds of cumulative backoff, then stop.
Never let 131000 retries share a policy with 400-class codes. Error 100, 132000, and 131050 fail identically on retry and each attempt consumes rate limit budget. If your HTTP client retries every non-2xx, you are burning quota on requests that can never succeed and risking error 4 on top.
Watch the aggregate, not the individual. A single 131000 is noise. A 131000 rate running above your normal baseline for several minutes is a signal. Alert on the rate, not on occurrences.
When It Stops Being Transient
This is the judgement call the documentation does not make for you. Three tests separate a genuine platform blip from something on your side wearing a 500.
Test 1 — Does it follow the payload or the platform? Send the same message content to a different recipient. If that succeeds, the failure is tied to something in the original payload or recipient, and no amount of retrying the original will help. If it also fails, you are looking at a platform-level problem.
Test 2 — Does it follow one template? If 131000 clusters on a single template while others send normally, inspect that template's components, media, and parameter values. A malformed media reference can surface as an unclassified failure rather than as error 131053.
Test 3 — Is the status page clean? Meta's recommended action for the sibling code 131016 is to check the WhatsApp Business Platform Status page. Do that for 131000 too. A known incident turns an investigation into a wait.
If all three point at a persistent, payload-independent failure, you have crossed from retry into escalation.
Opening a Direct Support Ticket
Meta's recommended action names Direct Support explicitly, and the quality of what you bring determines whether the ticket goes anywhere.
Collect before you file:
fbtrace_idvalues from several failed responses. This is the single most important item — it is how Meta locates your specific requests in their logs. If your logging captures onlyerror.message, you do not have them, and that gap is worth fixing today regardless.- Timestamps in UTC for the first and most recent failures.
- Your phone number ID and WABA ID.
- The full request payload with any personal data redacted.
- The failure rate, expressed as failures over total attempts across a stated window. "Roughly 12% of sends over the last four hours" is actionable; "it keeps failing" is not.
- What you already ruled out — the three tests above. Showing your work shortens the exchange considerably.
If you work through a Business Solution Provider, raise it there first. A BSP has an escalation path into Meta and has usually seen the pattern across multiple customers, which is often faster than filing directly.
Reducing Your Exposure
131000 is not preventable, since the failure is on Meta's side. What is controllable is how much it costs you when it happens.
Queue durably. Messages should survive a failed send and a process restart. An in-memory retry loop loses the message when the pod recycles mid-incident.
Log the whole error object. Not error.message. The fbtrace_id and error_data.details live in the nested structure, and discarding them is what makes 131000 feel undebuggable.
Separate transactional from promotional flows. During an incident you want the ability to keep order notifications flowing while pausing a campaign. Running them through different queues, and ideally different phone numbers, makes that a decision rather than an outage. Our guide to multiple numbers on one WhatsApp Business Account covers the setup.
Alert on rate, page on sustained rate. A brief spike resolves itself. Twenty minutes of sustained 131000 against a clean status page deserves a human.
Worth noting for finance and operations: a message that fails with 131000 was never delivered, so it does not become a billable delivered message under the per-message pricing Meta adopted on 1 July 2025 (Meta for Developers, Pricing, retrieved 2026-08-20). The cost of an incident is reach and timeliness, not spend.
Frequently Asked Questions
What does WhatsApp error 131000 mean?
Meta documents it as "Something went wrong," with details stating the message failed to send due to an unknown error, returned with HTTP status 500. It is a genuine server-side failure that Meta could not classify into a more specific code. The recommended action is to try again, and to open a Direct Support ticket if it persists.
Should I retry after error 131000?
Yes — this is one of the few WhatsApp codes where retrying is correct, because the 500 indicates a Meta-side failure rather than a bad request. Use exponential backoff with jitter, cap at three to five attempts and roughly thirty seconds total, then move the message to a durable dead-letter queue and alert. Do not retry indefinitely.
How do I know whether 131000 is a Meta problem or mine?
Run three checks. Send the same content to a different recipient — if that works, the issue is tied to your payload or that recipient. Check whether failures cluster on one template. And check the WhatsApp Business Platform Status page, which Meta names in its guidance for the related code 131016. A payload-independent, persistent failure with a clean status page is worth escalating.
What information does Meta need in a Direct Support ticket?
fbtrace_id values from several failed responses above all, since that is how Meta locates your requests. Add UTC timestamps for first and latest failure, your phone number ID and WABA ID, a redacted sample payload, the failure rate over a stated window, and what you have already ruled out.
What is the difference between error 131000 and 131016?
Both return HTTP 500. Meta documents 131016 as "Service unavailable," meaning a service is temporarily unavailable, with a recommended action of checking the platform status page before retrying. Error 131000 is the broader unclassified failure. In practice 131016 is the more informative of the two, because it points at a known service condition.
Retry Well, Escalate With Evidence
Error 131000 is easy to handle badly in two opposite directions. Teams either retry it forever, converting a brief Meta incident into their own rate limit problem, or treat it as a bug in their own code and spend a day debugging a request that was fine.
The middle path is short: bounded backoff with jitter, a durable queue behind it, and three quick tests to decide whether you are still in transient territory. If you are not, the ticket you file with fbtrace_id values and a stated failure rate gets a real answer. The one without them does not.
Want send reliability handled at the platform layer? Helo.ai is a Meta Partner with 25 years of enterprise communication experience, running durable queuing, backoff, and incident escalation for enterprise WhatsApp programmes. Talk to an expert.
Next: error 4 for the backoff patterns in full, or error 131026 if failures turn out to be recipient-specific rather than platform-wide.
