WhatsApp error 131051 (unsupported message type): inbound and outbound causes explained

WhatsApp error 131051 means "Unsupported message type". Meta's error reference gives that description and one instruction: see the list of supported message types before trying again with a supported type. In practice the code turns up in two different places, and the fix depends on which one you are looking at. If it came in a webhook for a message a customer sent you, WhatsApp is telling you it could not pass that message's content to the API. If it came back on a message you sent, the request asked for a type the Cloud API does not support.

Case 1: an incoming message you cannot read

Meta's unsupported messages webhook reference lists three triggers for a message with type: "unsupported":

1. A WhatsApp user sends a message type not supported by the Cloud API.
2. You use the API to send a message to a number already in use with the API. The Cloud API then sends the webhook to the owner of the recipient number.
3. A WhatsApp user messages a business onboarded with a WhatsApp Business app number for the first time, which is especially common after a Click-to-WhatsApp ad.

The first two carry code 131051. The third carries 131060, "This message is currently unavailable.", which is a coexistence behaviour, not an unsupported type. Here is the webhook for the first case (values illustrative):

{
  "object": "whatsapp_business_account",
  "entry": [{
    "id": "102290129340398",
    "changes": [{
      "field": "messages",
      "value": {
        "messaging_product": "whatsapp",
        "metadata": { "display_phone_number": "919810012345", "phone_number_id": "106540352242922" },
        "contacts": [{ "profile": { "name": "Priya" }, "wa_id": "919876543210" }],
        "messages": [{
          "from": "919876543210",
          "id": "wamid.HBgMOTE5ODc2NTQzMjEwFQIAEhgU...",
          "timestamp": "1761810000",
          "type": "unsupported",
          "unsupported": { "type": "poll_creation" },
          "errors": [{
            "code": 131051,
            "title": "Message type unknown",
            "message": "Message type unknown",
            "error_data": { "details": "Message type is currently not supported." }
          }]
        }]
      }
    }]
  }]
}

The useful field is unsupported.type. Meta's reference lists these values: button, edit, errors, gif, group_invite, hsm, image, interactive, keep_in_chat, link_preview, list, location, media_placeholder, order, pin, poll_creation, poll_update, product and reaction. Some names, such as image or location, are ordinary types; they appear here when a particular variant of them cannot be passed through. Meta extended this list in February 2026, so treat it as open-ended and do not crash on a value you have not seen.

What to do about an unsupported incoming message

• Nothing is broken. You cannot change what the customer's app sends, and there is no setting that makes these types available.
• Ask for the content another way. If the message matters, reply inside the open customer service window and ask the customer to send it as plain text, a normal photo or a document.
• Still record that they wrote. An unsupported message is a real inbound message from the customer. Store it, show it to the agent and treat the conversation as active.
• Do not let it break your code. Parsers that expect a text.body or a media ID on every message crash on type: unsupported. Handle unknown types with a default branch.
• For case 2, check why another API number is messaging yours. It is often a test setup where one Cloud API number sends to another.

Case 2: a message you sent fails with 131051

When 131051 comes back in the response to your own /messages request, or in a failed status for it, the request asked for a type the API does not accept. Meta lists the service message types you can send in an open window: address, audio, contacts, document, image, interactive (CTA URL buttons, voice call, Flows, lists, location requests and reply buttons), location, sticker, text, video and reaction messages. Outside the window, only template messages are allowed, and those fail with 131047, not 131051.

Common outbound causes:

• A misspelt or invented type, for example "type": "buttons" or "type": "poll".
• A type copied from an incoming webhook, such as unsupported, button, order or system, which describe received messages and cannot be sent.
• Mixing message shapes, for example "type": "text" with an image object, or an interactive object whose own type is not one Meta supports.

A failing request and its fix (illustrative):

{
  "messaging_product": "whatsapp",
  "to": "919876543210",
  "type": "poll",
  "poll": { "question": "Which colour do you prefer?" }
}

There is no poll type for business messages. Use interactive reply buttons for up to three choices, or an interactive list for more:

{
  "messaging_product": "whatsapp",
  "to": "919876543210",
  "type": "interactive",
  "interactive": {
    "type": "button",
    "body": { "text": "Which colour should we keep aside for you?" },
    "action": {
      "buttons": [
        { "type": "reply", "reply": { "id": "indigo", "title": "Indigo" } },
        { "type": "reply", "reply": { "id": "mustard", "title": "Mustard" } },
        { "type": "reply", "reply": { "id": "rust", "title": "Rust" } }
      ]
    }
  }
}

A worked example

Meera at Rangoli Home asks customers who recently chatted with the brand which cushion colour to restock, and invites them to reply. Some customers answer by creating a poll in the chat. Her developer, Arjun, sees those replies arrive in the webhook as type: unsupported with unsupported.type: poll_creation and code 131051, and the store's old parser was dropping them silently.

He makes two changes. The parser now saves every unsupported message with a short notice so the team can see the customer wrote. And instead of inviting free-form answers, the follow-up message uses three reply buttons, which arrive as normal interactive replies the system can count.

Handling 131051 in code

function toInboxMessage(msg: any) {
  switch (msg.type) {
    case 'text': return { kind: 'text', text: msg.text.body };
    case 'image': return { kind: 'media', mediaId: msg.image.id };
    // … other supported types
    case 'unsupported': {
      const sub = msg.unsupported?.type ?? 'unknown';
      const code = msg.errors?.[0]?.code;   // 131051 or 131060
      return { kind: 'notice', text: `Customer sent a ${sub} message the API cannot show (code ${code}).` };
    }
    default: return { kind: 'notice', text: `Unhandled message type: ${msg.type}` };
  }
}

For outbound sends, validate type against an allow-list before calling the API, so a typo fails in your own code with a clear message instead of a 131051 from Meta.

How Broadchat handles unsupported messages

In Broadchat's Inbox, an incoming unsupported message appears as a bubble with a notice that WhatsApp did not deliver the content of this message to the API, and a suggestion to ask the sender to resend it as normal text, instead of an empty bubble or a missing message. Unsupported messages do not trigger chatbot flows and are not counted as campaign replies, so a poll or edit cannot set off an automation by accident. Messages you send from the panel and the chatbot builder are built from supported types, so 131051 on outbound sends normally comes from your own API integrations.

For the rest of the codes, see the WhatsApp API error codes cheat-sheet; for the message types you can design, see interactive messages and reply buttons. If you are new to the platform, start with the plain-English guide to the WhatsApp Business API.