🐛 Describe the Bug
When receiving an inbound WhatsApp media message through the InboundMessage app webhook, the webhook payload does not include attachments. It sends body as empty and contentType as text/plain.
However, when querying the same messageId using GET /conversations/messages/{messageId}, the attachments array is available a few seconds later, not inmediately.
📍 API Endpoint
/webhook/InboundMessage
✅ Expected Behavior
InboundMessage webhook should include attachments for WhatsApp media messages, and contentType as media/jpeg, etc
💻 Screenshots or Code Samples
No response
Product Area
conversations
📋 Use Case
We use the InboundMessage app webhook to process inbound WhatsApp messages in n8n and trigger AI-based responses.
For text messages, the webhook payload works correctly. However, for inbound WhatsApp media messages such as images, videos, audio notes, and documents, the webhook payload arrives without the attachments field.
We need the attachments field in the InboundMessage webhook to:
- Detect when a customer sent media through WhatsApp
- Download and process images, audio, video, and documents
- Transcribe audio messages
- Analyze images/documents with AI
- Respond to the customer through the Conversations API
- Avoid having to poll GET /conversations/messages/{messageId} after every empty WhatsApp message
Current webhook behavior:
- body is empty
- contentType is text/plain
- attachments is missing
Expected behavior:
The InboundMessage webhook should include the same attachments array that is available when querying GET /conversations/messages/{messageId}, or the documentation should clearly state that WhatsApp media attachments are hydrated asynchronously and require a follow-up GET request.
🚨 Why Should This Be Prioritized?
This should be prioritized because it prevents reliable automation for WhatsApp media messages.
Our customers send images, videos, audio notes, and documents through WhatsApp. When the InboundMessage webhook does not include attachments, our automation cannot determine whether the customer sent media or process the file immediately.
This impacts:
- AI processing of WhatsApp audio notes
- Image/document analysis
- Customer support automations
- Response time, because we must add delays and extra API calls
- API usage, because we now need to call GET /conversations/messages/{messageId} after receiving empty WhatsApp messages
In our test, the same messageId had no attachments in the InboundMessage webhook, but after calling GET /conversations/messages/{messageId}, the attachments array was available. This suggests the webhook is fired before the message is fully hydrated with media data.
A reliable webhook payload would reduce latency, reduce API calls, and make WhatsApp media automation possible without workaround logic.
🧠 Additional Context
No response
🐛 Describe the Bug
When receiving an inbound WhatsApp media message through the InboundMessage app webhook, the webhook payload does not include attachments. It sends body as empty and contentType as text/plain.
However, when querying the same messageId using GET /conversations/messages/{messageId}, the attachments array is available a few seconds later, not inmediately.
📍 API Endpoint
/webhook/InboundMessage
✅ Expected Behavior
InboundMessage webhook should include attachments for WhatsApp media messages, and contentType as media/jpeg, etc
💻 Screenshots or Code Samples
No response
Product Area
conversations
📋 Use Case
We use the InboundMessage app webhook to process inbound WhatsApp messages in n8n and trigger AI-based responses.
For text messages, the webhook payload works correctly. However, for inbound WhatsApp media messages such as images, videos, audio notes, and documents, the webhook payload arrives without the attachments field.
We need the attachments field in the InboundMessage webhook to:
Current webhook behavior:
Expected behavior:
The InboundMessage webhook should include the same attachments array that is available when querying GET /conversations/messages/{messageId}, or the documentation should clearly state that WhatsApp media attachments are hydrated asynchronously and require a follow-up GET request.
🚨 Why Should This Be Prioritized?
This should be prioritized because it prevents reliable automation for WhatsApp media messages.
Our customers send images, videos, audio notes, and documents through WhatsApp. When the InboundMessage webhook does not include attachments, our automation cannot determine whether the customer sent media or process the file immediately.
This impacts:
In our test, the same messageId had no attachments in the InboundMessage webhook, but after calling GET /conversations/messages/{messageId}, the attachments array was available. This suggests the webhook is fired before the message is fully hydrated with media data.
A reliable webhook payload would reduce latency, reduce API calls, and make WhatsApp media automation possible without workaround logic.
🧠 Additional Context
No response