first message from click-to-WhatsApp ad leads is shown as "unsupported message type" and does not trigger flows
Status: Closed · Asked by Andrea Lanari on · 0 views
Hello Andrea,
Thank you for sharing the details and screenshots.
Based on the error message and the logs, it appears that the format of the message sent by the user is not supported by the WhatsApp Cloud API. The error code 131060 with the message "This message is unavailable" suggests that the restriction is originating from WhatsApp’s end, not from the Chatflow or integration setup.
Since the same message is visible in the WhatsApp Business app but fails in the API response, it's likely that WhatsApp's cloud infrastructure is unable to process certain types of messages (e.g., media, unsupported formatting, or ephemeral content) via API.
https://developers.facebook.com/docs/whatsapp/embedded-signup/custom-flows/onboarding-business-app-users/
Regarding the webhook payloads, we will need to analyze the logs to provide accurate information about the type of messages received and their attributes.
We have escalated this to our technical team to provide you with the requested information shortly. We appreciate your patience while we work to resolve this matter effectively.
Thanks & Regards,Arshil Ahmad
🌐 Pabbly.com
Hello Andrea,
I hope you’re doing well. I just wanted to follow up regarding our last message.
Thanks & Regards,
Adeel Akhtar
🌐 Pabbly.com
thank you
Hi Arshil,
Thanks for following up — the issue is still open and unresolved on our side, so please keep the technical escalation running.
We are not in a position to accept a root cause yet, and we would ask your technical team to establish it from the raw logs rather than from the inbox display. Here is why, and here is the full set of facts.
TWO DIFFERENT ERRORS
Our inbox displays: "WhatsApp Cloud API does not support this message type. Try using a different format."
Your reply cites error 131060, "This message is unavailable."
Those are not the same error. Since Chatflow surfaced an error code that does not match the one you report from your logs, we cannot treat anything shown in the inbox as evidence of what is actually happening. This has to be established from the raw webhook payloads.
YOUR EARLIER EXPLANATION DOES NOT MATCH OUR EVIDENCE
You suggested media, unsupported formatting or ephemeral content, and referred to Instagram ad clicks. Our observations contradict all of this:
- The messages are plain text. Example: "E1 Hola, quiero participar en el Grupo GRATIS del Reto Start."
- They display completely normally in the WhatsApp Business app on the same number. Screenshots of both views for contact 34622952407 were attached previously.
- The failures are not specific to Instagram, and not specific to ads at all. See below.
OBSERVED FACTS
1. SCOPE. Approximately 7% of all first inbound messages from new contacts fail. We have reviewed several hundred contacts to establish this figure, and it has been consistent throughout.
2. IT IS NOT AD-SPECIFIC. The failures occur on leads from Meta click-to-WhatsApp ads AND on organic contacts who reach us through our coaches' own links. Different entry points, same failure, same rate. Any explanation specific to ad click messages does not account for what we are seeing.
3. The contact is created correctly in Chatflow: phone number, profile name, Allowed & Opt-In, 24-hour window Active.
4. The message body is not available. No flow is triggered. No webhook reaches our automation. The lead is lost silently, with no error surfaced anywhere we can act on programmatically.
5. Our number runs in coexistence mode: registered simultaneously in the WhatsApp Business app and in Cloud API via Chatflow.
6. The same message is fully readable as plain text in the WhatsApp Business app.
7. It affects the FIRST message only. When we manually message a failed contact and they reply, that second message triggers our flow normally — identical text, identical sender, same number.
8. NO PATTERN IN AD, CAMPAIGN, PLACEMENT OR MARKET. The same Facebook ad produces both failures and successes. Failures span multiple campaign tokens, and so do successes. Failures occur in both Spain (+34) and Mexico (+52). The same placement produces both outcomes.
9. NO PATTERN IN TIME OF DAY. Failures occur across all hours. This is not confined to any maintenance or deployment window.
10. SAMPLE CONTACTS. These are examples from a much larger set, not the complete list: 34622952407, 34681395484, 34699146508, 34691179583, 34610608759, 522382730369. We can supply many more, with exact timestamps and message IDs, on request.
WHAT WE NEED FROM YOU
1. The raw webhook payloads Chatflow received for those contacts. Specifically: the actual error code, the message type Meta sent, what the payload contained, and which webhook event it arrived on.
2. Confirmation of whether "WhatsApp Cloud API does not support this message type. Try using a different format." is text generated by Chatflow or literal text returned by Meta. If Chatflow generates it and maps it from a different underlying error, that is worth correcting on your side — it cost us several days of misdiagnosis.
3. Your technical team's determination of the actual cause, based on those payloads.
4. Separately, and independent of whatever the cause turns out to be: Chatflow receives these events, since it renders them in the inbox. Can Chatflow expose them to us — a flow trigger, an outbound webhook, or a notification when an inbound message cannot be processed, carrying the contact's phone number? Detection is entirely manual today: someone has to open the inbox and notice. This would let us automate recovery regardless of root cause.
Coexistence is a fixed requirement on our side. Please do not propose removing the number from the WhatsApp Business app.
At 7% of all new inbound contacts, across both paid and organic acquisition, this is a significant and ongoing loss at the entry point of our funnel. A definitive answer, including "this is a known platform limitation", is more useful to us than a partial workaround.
Thanks,
Andrea
Hello,
1. {
"level": "info",
"message": "Incoming webhook event received through queue:",
"meta": {
"body": {
"object": "whatsapp_business_account",
"entry": [
{
"id": "289284307600605",
"changes": [
{
"field": "messages",
"value": {
"messaging_product": "whatsapp",
"metadata": {
"display_phone_number": "34611148613",
"phone_number_id": "233349146539117"
},
"contacts": [
{
"profile": {
"name": "Adri"
},
"user_id": "ES.1029969919812873",
"wa_id": "34622952407"
}
],
"messages": [
{
"id": "wamid.HBgLMzQ2MjI5NTI0MDcVAgASGBQzQUFENDBFMjU5RTFFQzkxMzEwOAA=",
"from": "34622952407",
"from_user_id": "ES.1029969919812873",
"timestamp": "1786140757",
"type": "unsupported",
"unsupported": {
"raw_type": "unknown",
"type": "unknown"
},
"errors": [
{
"code": 131060,
"title": "This message is unavailable.",
"message": "This message is unavailable.",
"error_data": {
"details": "This message is currently unavailable."
}
}
]
}
]
}
}
]
}
]
},
},
"timestamp": "2026-08-07T22:12:38.354Z"
}
2. Confirmation of whether "WhatsApp Cloud API does not support this message type. Try using a different format." is text generated by Chatflow or literal text returned by Meta. If Chatflow generates it and maps it from a different underlying error, that is worth correcting on your side — it cost us several days of misdiagnosis.
This appears to be Pabbly Chatflow's response to the error message received from Meta. When you hover over the message, the actual error received from Meta is displayed.
Since error code 131060 is related to the message format, Chatflow currently displays it accordingly. However, I have informed our technical team about this, and they will look into displaying the correct error message.
3. Your technical team's determination of the actual cause, based on those payloads.
The issue is from Meta's end as can be seen in the payload received.
4. Separately, and independent of whatever the cause turns out to be: Chatflow receives these events, since it renders them in the inbox. Can Chatflow expose them to us — a flow trigger, an outbound webhook, or a notification when an inbound message cannot be processed, carrying the contact's phone number? Detection is entirely manual today: someone has to open the inbox and notice. This would let us automate recovery regardless of root cause.
This is currently not possible. However, you can submit your request on our dedicated feature request platform, where our Product and Development teams can review it and consider adding the requested feature if feasible.
https://roadmap.pabbly.com/pabbly-chatflow
Hi Arshil,
Thank you — the raw payload is exactly what we needed, and it settles the question. We can see that Meta delivered the message as type "unsupported" with raw_type "unknown" and error 131060, with no message body. Chatflow received an empty message. We accept that the loss originates at Meta's end and we are not asking you to fix delivery.
We also appreciate you passing the error-display issue to your technical team. Showing 131060 as a message format problem is what sent us down the wrong diagnostic path, so correcting that will help other customers too.
Three remaining requests, all on the visibility side.
1. LOG ACCESS FOR OUR OWN ANALYSIS
We would like to inspect these payloads ourselves rather than requesting them case by case. Around 7% of our new inbound contacts fail this way, across both paid and organic entry points, and we want to look for variables across a large sample — not just confirm individual cases.
Is there any way for us to access the raw incoming webhook payloads for our own account? Any of these would work for us:
- A log or event viewer in the Chatflow interface showing raw inbound webhook payloads
- An API endpoint we can query for inbound message events, including failed ones
- A periodic export we can request
If none of these exist today, please tell us plainly so we can plan around it.
2. HOVER DETAIL
You mentioned the actual Meta error is shown on hover. Could you confirm exactly what that tooltip contains — does it show the full error object, the error code, or only the title? We want to know how much we can extract manually from the inbox while we wait for anything better.
3. BSUID IN FLOWS
The payload includes "user_id": "ES.1029969919812873" and "from_user_id" for this contact. So Chatflow is receiving business-scoped user IDs from Meta.
Is user_id exposed as a usable variable inside Chatflow flows, and is it passed through to API Request nodes? This matters to us separately, because Meta's username rollout reaches our markets from September 2026, and we need to know whether we can identify contacts by BSUID when a phone number is not available. We have a separate open ticket on that topic — happy to move this question there if you prefer.
We will submit the notification/trigger request through the feature request platform as you suggested.
Thanks,
Andrea
No, currently, it is not possible to fetch or extract the raw webhook data directly from the Pabbly Chatflow interface, and there is no API endpoint available for this either.
I was referring to this message. If you hover over the Pabbly Chatflow message, you will see the error message received from Meta.
It would be better to continue this discussion in the other thread, as a ticket has already been created there for the same issue.
Just following up regarding this—please review the points shared above
Just following up one last time regarding this. We haven't heard back from you, so we'll be closing this ticket for now. If you need any further assistance, simply send an email to support@pabbly.com.
Yes, thank you so much