Cloud API (WHATSAPP-BUSINESS): status webhook (sent/delivered/read) crashes messageHandle with "Cannot read properties of undefined (reading 'name')" — Chatwoot stuck on "failed to send" even though message is delivered

[drivas22]

Description

When Evolution API is running an instance with integration: "WHATSAPP-BUSINESS" (official WhatsApp Cloud API, not Baileys) connected to Chatwoot, every incoming Meta webhook that carries a statuses array (i.e. a sent/delivered/read status update for a message we sent) crashes with:

TypeError: Cannot read properties of undefined (reading 'name')
    at Ls.messageHandle (/evolution/dist/main.js:231:774)
    at Ls.eventHandler (/evolution/dist/main.js:231:9623)

This happens for every status event (sent, delivered, read) of the same message. Because the handler throws before it can relay the status update to Chatwoot, the message sent from Chatwoot stays marked as "Falha ao enviar" (failed to send) and the delivery/read ticks never update in the Chatwoot UI — even though the message was actually delivered and read on the recipient's WhatsApp. This makes the Chatwoot sent/failed indicator unreliable when using the Cloud API integration.

Right after this, a related error also shows up in the log for the same message:

ERROR [ChatwootService] Error updating Chatwoot message source ID: Error: getaddrinfo EAI_AGAIN host
ERROR [unhandledRejection] { status: 400, error: 'Bad Request', message: [ 'Method not available on WhatsApp Business API' ] }

Not sure if it's the same root cause or a second issue, but it appears in the same flow right after the TypeError above.

Suspected cause (not confirmed against source, dist/main.js is minified)

The handler appears to unconditionally read contacts[0].profile.name from the Meta webhook payload. That field is present when the payload is a real inbound message:

{ "contacts": [{ "profile": { "name": "John Doe" }, "wa_id": "REDACTED", "user_id": "REDACTED" }] }

...but is absent on a status-only payload, where contacts[0] only has wa_id/user_id, no profile key at all:

{
"messaging_product": "whatsapp",
"metadata": { "display_phone_number": "REDACTED", "phone_number_id": "REDACTED" },
"contacts": [{ "wa_id": "REDACTED", "user_id": "REDACTED" }],
"statuses": [{ "id": "wamid...", "status": "delivered", "timestamp": "REDACTED", "recipient_id": "REDACTED", "recipient_user_id": "REDACTED", "pricing": { } }]
}

Reading .profile.name on that second shape throws.

To Reproduce

1. Create an instance with integration: "WHATSAPP-BUSINESS", a real Cloud API phone number/token, and Chatwoot enabled (/chatwoot/set/:instance).
2. 2. Configure the Meta app's webhook (messages field subscribed) pointing at /webhook/meta.
3. 3. Send a message from Chatwoot to a real WhatsApp number.
4. 4. Watch docker compose logs -f evolution-api — as soon as Meta sends back the sent/delivered/read status webhooks for that message, the TypeError above is thrown for each one.
5. 5. In Chatwoot, the outbound message stays marked as failed / ticks never advance, despite the message actually being delivered on the recipient's phone.

Expected behavior

Status-only webhook payloads (payloads with a statuses array and no profile on contacts[0]) should be handled without throwing, and should update the corresponding message status in Chatwoot (sent/delivered/read), matching what actually happens on WhatsApp.

Environment

• Evolution API version: 2.3.7 (image evoapicloud/evolution-api:latest, pulled 2026-08-25)
• • Integration: WHATSAPP-BUSINESS (official Cloud API), not Baileys
• • • Chatwoot integration enabled via /chatwoot/set/:instance, using internal Docker networking (http://chatwoot-web:3000)
• • • • Docker Compose deployment, Node.js container
• • • • • WA_BUSINESS_VERSION: v20.0 in the container env; the Meta app's webhook fields are subscribed at v26.0 (not sure if this version mismatch is related)

Additional context

This only affects the Cloud API (WHATSAPP-BUSINESS) integration's status-webhook handling — inbound message receipt works correctly once the webhook and app are configured properly, and the actual send to WhatsApp succeeds (confirmed by the message being delivered and read on the recipient's device). Only the status feedback loop back into Chatwoot is broken.

(Replaces #2709, which was closed after briefly containing test data that has since been redacted — this is a clean re-post of the same report.)

(Replaces #2709, which was closed after briefly containing test data that has since been redacted — this is a clean re-post of the same report.)