WhatsApp Error 131051: Unsupported Message Type

WhatsApp error 131051 means an unsupported message type — often inbound edited, deleted, poll, or unavailable messages hitting your webhook handler. What to do.

TL;DR: WhatsApp error 131051 means an unsupported message type was encountered. Meta's error-table details string is "Unsupported message type." Most teams meet 131051 inbound: when a user sends something the Cloud API can't represent (edited, deleted/revoked, poll, or otherwise unavailable messages), the webhook delivers a message with type: unsupported carrying error 131051. The fix is to handle these gracefully in your inbound handler.

What Error 131051 Means

131051 covers message types the Cloud API does not support. On Meta's error-codes table the details value is:

"Unsupported message type."

In the inbound unsupported messages webhook, Meta's own example (reference page "Updated: May 21, 2026") shows the error object verbatim as "code":131051,"title":"Message type unknown","error_data":{"details":"Message type is currently not supported."},"type":"unsupported" — and in that example unsupported.type is edit, confirming edited messages surface this way. Possible unsupported subtypes Meta lists include button, edit, gif, group_invite, interactive, location, order, poll_creation, poll_update, product, and reaction, among others.

Where You See It

Primarily inbound, via webhook. The notification arrives in entry.changes.value.messages[] with type: unsupported and an errors[] array containing code 131051. Per Meta's messages webhook reference: incoming message errors appear in the messages array and these webhooks have type set to unsupported. It can also appear synchronously if you attempt to send a type the API doesn't support, but the inbound case dominates real-world demand. Note: these webhooks arrive as new inbound events, so the id won't match a message you sent.

Common Causes

  • A user edited a message (surfaces as unsupported.type: edit).
  • A user deleted/revoked a message — the Cloud API does not provide a delete status, so you receive an unsupported-type error instead.
  • The user sent a poll, group invite, product, GIF, or other type the Cloud API can't render.
  • Coexistence / companion-device limitations: messages from some unsupported devices arrive as unsupported (often related to error 131060, "message unavailable").
  • Attempting to send a message type not supported by the endpoint.

How to Fix It

  1. In your inbound handler, branch on messages[].type. When it equals unsupported, read errors[0].code (131051) and errors[0].error_data.details.
  2. Do not crash or treat it as a normal message. Store a placeholder ("unsupported message received") and continue.
  3. If you need the content, prompt the user via a supported channel/type to resend.
  4. If 131051 came from a send attempt, switch to a supported message type (see Meta's Messages → message types reference).
  5. Distinguish 131051 (unsupported type) from 131060 (message unavailable) since coexistence scenarios can produce either.

How to Prevent It

  • Treat type: unsupported as a first-class case in your webhook router, not an exception.
  • Log the unsupported.type subtype so you can quantify how often edits, deletions, or polls occur.
  • For senders, validate message type against the supported list before calling the API.

Related Errors

FAQ

Q: Why do I get 131051 webhooks that don't match any message I sent? A: They're inbound events — a user edited, deleted, or sent an unsupported type. The id is the user's message, not yours.

Q: What's the exact inbound title and details? A: Meta's example shows title Message type unknown and details Message type is currently not supported.

Q: Does a deleted message give a delivery status? A: No — the Cloud API has no delete status, so you instead receive an unsupported-type message with 131051.

Q: Is 131051 the same as 131060? A: Related but distinct: 131060 is "message unavailable" (common with coexistence/companion devices); 131051 is "unsupported message type."

How Dualhook Helps

Honest answer: 131051 is an inbound-handler matter, and inbound messages webhooks go straight from Meta to your endpoint — Dualhook routes via Meta's override_callback_uri and is not in the message path, so it never reads or stores the content of these messages. Your code must branch on type: unsupported. Dualhook's relevant role is webhook routing and subscription health: it helps ensure your endpoint is correctly subscribed and receiving the messages field so these events actually reach you. See Messaging Webhook, Webhook Events & Notifications, and WhatsApp Coexistence for the companion-device cases.

Browse more docsStart Free Trial