WhatsApp error 135000 (generic user error): narrow down a request Meta could not understand

WhatsApp error 135000 means the Cloud API could not send your message because of an unknown problem with the request parameters. Meta's error reference describes it as "Message failed to send because of an unknown error with your request parameters" and suggests you "see the endpoint's reference to determine if you are querying the endpoint using the correct syntax" and "contact customer support if you continue receiving this error code in response". Meta lists it with HTTP 500 Internal Server Error. Think of it as the parameter-side cousin of 131000: something in what you sent tripped Meta up, and the message does not say which part.

Why it is harder than other parameter errors

Most request errors name the problem. 131008 names a missing field, 131009 a bad value and 132012 a template value in the wrong format. 135000 gives you none of that, so guessing wastes time. A method works better than intuition:

Step-by-step: isolate the field

1. Capture the exact request your code sent, after all templating, with the access token removed. Many bugs live in what the code built, not what you meant.
2. Send a minimal message from the same server, token and phone number ID:

{
  "messaging_product": "whatsapp",
  "to": "919812345678",
  "type": "text",
  "text": { "body": "Test from the server" }
}

If this fails too, the problem is the endpoint, version or account, not your payload.

3. Add fields back in halves. Put back half of what you removed. Still working? Add the next half. Failing? The problem is in the half you just added. Repeat until one field remains.
4. Inspect that field byte by byte. Look for zero-width spaces, non-breaking spaces and smart quotes copied from Excel or Google Sheets, a stray \u0000, or text that is not valid UTF-8.
5. Check the endpoint and version. Make sure you post to /<PHONE_NUMBER_ID>/messages on a supported Graph API version and that the field you are using exists in that version's reference.
6. Build JSON with a library, never by joining strings. A customer name with a quote mark (Arjun "AJ" Mehta) breaks hand-built JSON in ways that are hard to spot.
7. Retry once, not in a loop. If the clean minimal request succeeds and your fixed payload succeeds, you are done. If an unchanged request fails repeatedly, more retries will not help.

What it looks like

Illustrative response (Meta's message text varies):

{
  "error": {
    "message": "(#135000) Generic user error",
    "type": "OAuthException",
    "code": 135000,
    "fbtrace_id": "AkP2vN7rTq3XbW9mLc5sGdE"
  }
}

Keep the fbtrace_id. It is the one value Meta support can use to find your request in their logs.

A worked example

Priya, a freelance developer in Indore, connects a coaching institute's admission CRM to the Cloud API. Fee reminders work for most students, but about 30 rows a day (illustrative) fail with 135000. The minimal test message works, so the endpoint and token are fine. Sending one failing row's payload with fields removed in halves leads her to the body text of an interactive reply-button message.

Those rows have student names pasted from a PDF admission form. A hex dump shows a zero-width joiner and a soft hyphen inside the names, and in one case a name longer than the field allows once a fee amount of ₹18,500 and a long batch name are appended. She normalises names on import (strip control and zero-width characters, trim whitespace) and caps the assembled text at the documented length. The failures stop. She keeps her capture of the original request and fbtrace_id in case it returns, so a ticket would take minutes to write.

When to contact Meta support

Open a ticket through Meta's Direct Support or the developer support channel when a minimal, valid request keeps failing with 135000. Include:

• the full request body with the token removed
• the phone number ID and WhatsApp Business account ID
• the UTC timestamp of a failing call
• the fbtrace_id from the response
• what you already ruled out (minimal message works or not, other numbers work or not)

Preventing 135000

• Sanitise text on import, not at send time: normalise Unicode, remove control and zero-width characters.
• Validate payloads against the reference in tests, especially for interactive and template messages.
• Log the request beside the error, so a failure can be reproduced the same day.
• Upgrade Graph API versions deliberately, testing each message type you use.

How Broadchat shows 135000

Broadchat's Meta client returns every error with its code, subcode and fbtrace_id. Broadchat has no special explanation for 135000, so message info shows the code with Meta's own error text, and the fbtrace_id is kept with the error for a support ticket. For outgoing messages, Broadchat does not automatically retry a 5xx response, because Meta may already have accepted the message and a retry could send it twice. Messages built in the panel use supported types, so a 135000 you see is most often from your own integration's API calls or from unusual characters in contact data.

Full list of codes: the WhatsApp API error codes cheat-sheet. Sending templates from code? Follow how to send a template message with the API.