Feature Request: Expose Chatwoot Context in WAHA Webhook Events

[exclusiveticsc-lab]

Feature Request: Expose Chatwoot Context in WAHA Webhook Events

Problem

When using the Chatwoot App integration, WAHA receives messages from Chatwoot with all the required context to identify the original Chatwoot records, including:

• Chatwoot Message ID
• Chatwoot Conversation ID
• Chatwoot Inbox ID

However, when WAHA later emits webhook events such as:

• message.any
• message.ack
• message

this Chatwoot context is not available in the webhook payload.

As a result, external integrations cannot reliably correlate:

WhatsApp Message ID
↔
Chatwoot Message ID

without implementing custom databases, payload matching, text matching, timing correlation, or other workarounds.

This becomes especially important for delivery tracking and synchronizing the WhatsApp Message ID back into Chatwoot's source_id field.

Proposed Solution

When a message originates from the Chatwoot App integration, include Chatwoot identifiers in WAHA webhook events.

Example:

{
  "event": "message.ack",
  "session": "Whatsapp_Exclusivetic-32246793_CWID_1",

  "payload": {
    "id": "true_11111111111@c.us_3EB03204FB70CD986785BC"
  },

  "chatwoot": {
    "message_id": 12345,
    "conversation_id": 678,
    "inbox_id": 15
  }
}

Alternative Naming

The information could also be exposed under:

{
  "metadata": {
    "chatwoot_message_id": 12345,
    "chatwoot_conversation_id": 678,
    "chatwoot_inbox_id": 15
  }
}

or any other structure preferred by the project.

Why This Helps

Many users need to:

1. Receive message.any or message.ack
2. Obtain the WhatsApp Message ID generated by WAHA
3. Store that ID back into Chatwoot (messages.source_id)
4. Track delivery and read receipts

Currently this requires custom correlation logic.

Since WAHA already has access to these Chatwoot identifiers internally during message processing, exposing them in webhook events would provide a clean and reliable integration point.

This request is related to #557, but focuses specifically on the Chatwoot App integration.

Instead of arbitrary metadata, WAHA already has access to Chatwoot identifiers during processing and could expose them in webhook events.

Benefits

• No breaking changes
• Backward compatible
• No WhatsApp payload modification
• No Meta policy impact
• Easier Chatwoot synchronization
• Easier delivery tracking
• Easier third-party integrations

Real Use Case

Chatwoot → WAHA → WhatsApp

Later:

WAHA → message.ack

At this point the integration needs:

• WhatsApp Message ID (already available)
• Chatwoot Message ID
• Chatwoot Conversation ID
• Chatwoot Inbox ID

to update the original Chatwoot message and synchronize delivery status.

Having these fields directly available in webhook events would greatly simplify the integration.

Conclusion

Having these improvements would greatly help our community that integrates Chatwoot + Waha.

Thank you very much for your attention and help.

[exclusiveticsc-lab]

Additional finding:

WAHA already stores the mapping internally.

From the current container files:

• app_chatwoot_chatwoot_messages stores conversation_id + message_id
• app_chatwoot_whatsapp_messages stores chat_id + message_id
• app_chatwoot_message_mapping links chatwoot_message_id and whatsapp_message_id

So the Chatwoot context already exists internally.

The feature request is only to expose this existing mapping in webhook events such as message.any and message.ack.