[WebJs] - Inconsistent message ID format for group messages sent via API

[rafaheringer]

Describe the bug

Apparently, there’s an inconsistency in how message IDs are handled in a very specific scenario involving sending messages to groups. Events triggered through the Webhook for any group message — regardless of type — contain the following ID pattern:

(...)
"id": {
    "_serialized": "[email protected][email protected]"
  },
(...)

However, when checking the payload returned by the SendMessage method of the WAHA API, we receive the following pattern. Notice that it does not contain the last fragment, which would normally be the sender’s ID:

(...)
"id": {
    "fromMe": true,
    "remote": "[email protected]",
    "id": "3EB091474C1CE5341E8F3F",
    "_serialized": "[email protected]_3EB091474C1CE5341E8F3F"
  },
(...)

In this situation, all subsequent ACK events from group participants triggered via Webhook contain the full ID — meaning the last fragment with the sender’s ID is appended. However, this ID is invalid. We can easily confirm this by trying to fetch the message via the API. See the following message.ack event payload. Note the serialized ID containing the sender fragment:

{
    "id": "evt_01k6zvfrkz58gdm8d5tbjq8abd",
    "timestamp": 1759858123392,
    "event": "message.ack",
    "session": "773e604b-73b3-467a-a190-9a9a453920d4",
    "metadata": {},
    "me": {
        "id": "[email protected]",
        "pushName": "Rafael Heringer"
    },
    "payload": {
        "id": "[email protected][email protected]",
        "from": "[email protected]",
        "to": "[email protected]",
        "participant": "171567317258406@lid",
        "fromMe": false,
        "ack": 1,
(...)

If I try to look up this ID via the messages endpoint: GET /api/{session}/chats/[email protected]/messages/[email protected][email protected]

{
  "message": "Message not found",
  "error": "Not Found",
  "statusCode": 404
}

But if I manually remove the last fragment: GET /api/{session}/chats/[email protected]/messages/[email protected]_3EB091474C1CE5341E8F3F

{
  "id": "[email protected]_3EB091474C1CE5341E8F3F",
  "timestamp": 1759858122,
  "from": "[email protected]",
  "fromMe": true,
(...)

Version

{
    "version": "2025.9.1",
    "engine": "WEBJS",
    "tier": "PLUS",
    "browser": "/usr/bin/google-chrome-stable"
  }

Steps

To Reproduce Steps to reproduce the behavior:

1. With WAHA running, send a simple new message to a WhatsApp group using the /api/sendText route.
2. Take note of the response payload, especially the id property.
3. Inspect message.ack events and compare their id property.

Expected behavior

The ID returned in ACK events should match the actual message ID stored and returned by WAHA. In this scenario, where the message was sent via the API, the ID should be returned without the last fragment. Alternatively, WAHA could normalize the API response so that IDs always include the last fragment consistently.

I’m not entirely sure how this behaves for other event types (e.g., message.reaction, etc.).

Screenshots

[github-actions[bot]]

Portuguese

---

Descreva o bug

Aparentemente, há uma inconsistência em como os IDs de mensagem são tratados em um cenário muito específico, envolvendo o envio de mensagens para grupos. Os eventos desencadeados pelo Webhook para qualquer mensagem de grupo - independentemente do tipo - contêm o seguinte padrão de identificação:

`JSON (...) "eu ia": { "_seriedized": "[email protected][email protected]" }, (...) ``

No entanto, ao verificar a carga útil devolvida pelo método SendMessage da API Waha, recebemos o seguinte padrão. Observe que ele não contém o último fragmento, que normalmente seria o ID do remetente:

`JSON (...) "eu ia": { "Fromme": verdadeiro, "Remote": "[email protected]", "ID": "3EB091474C1CE5341E8F3F", "_seriedized": "[email protected]_3eb091474c1ce5341e8f3f" }, (...) `

Nesta situação, todos os eventos subsequentes da ACK dos participantes do grupo acionados por webhook contêm o ID completo - o que significa que o último fragmento com o ID do remetente é anexado. No entanto, esse ID é inválido. Podemos confirmar isso facilmente tentando buscar a mensagem através da API. Consulte a seguinte carga útil do evento Message.ack. Observe o ID serializado contendo o fragmento de remetente:

`JSON { "ID": "EVT_01K6ZVFRKZ58GDM8D5TBJQ8ABD", "Timestamp": 1759858123392, "Evento": "message.ack", "Sessão": "773E604B-73B3-467A-A190-9A9A453920D4", "Metadata": {}, "meu": { "ID": "[email protected]", "PushName": "Rafael Heringer" }, "Carga de pagamento": { "ID": "[email protected][email protected]", "de": "[email protected]", "para": "[email protected]", "Participante": "171567317258406@lid", "Fromme": falso, "ACK": 1, (...) `

Se eu tentar procurar este ID através do terminal das mensagens: Get/api/{session}/chats/[email protected]/mensagens/[email protected]_3eb091474c1ce5341e8f3f_5111377740714711 @Us `` JSON { "mensagem": "mensagem não encontrada", "Erro": "não encontrado", "StatusCode": 404 } `` `

Mas se eu remover manualmente o último fragmento: Get/api/{session}/chats/[email protected]/messhares/[email protected]_3eb091474c1ce5341e8f3f `JSON { "ID": "[email protected]_3eb091474c1ce5341e8f3f", "Timestamp": 1759858122, "de": "[email protected]", "Fromme": verdadeiro, (...) `

versão

`JSON { "versão": "2025.9.1", "motor": "webjs", "Tier": "Plus", "Navegador": "/usr/bin/google-crome-stable" } `

Passos

** Para reproduzir ** etapas para reproduzir o comportamento:

1. Com Waha em execução, envie uma nova mensagem simples para um grupo do WhatsApp usando a rota /api/sendText.
2. Observe a carga útil da resposta, especialmente a propriedade id.
3. Inspecione os eventos Message.ack e compare sua propriedade id.

comportamento esperado

O ID retornou nos eventos da ACK deve corresponder ao ID da mensagem real armazenado e devolvido por Waha. Nesse cenário, onde a mensagem foi enviada através da API, o ID deve ser devolvido sem o último fragmento. Como alternativa, Waha poderia normalizar a resposta da API para que os IDs sempre incluam o último fragmento de forma consistente.

Não tenho muita certeza de como isso se comporta para outros tipos de eventos (por exemplo, message.reation etc.).

screenShots

[rafaheringer]

Nothing here?

[devlikepro]

we need to delve deeper into this