Environment
- WAHA version:
2026.3.4
- Engine:
NOWEB (Baileys)
- Tier: PLUS
- Platform: linux/x64
- Webhook event:
message
Summary
Animated GIFs sent through WhatsApp arrive in NOWEB as videoMessage with mimetype: "video/mp4" and gifPlayback: true. This is probably expected from WhatsApp/Baileys, but downstream consumers need to dig into _data.message.videoMessage to preserve GIF semantics.
It would be helpful if WAHA exposed the GIF-related metadata in the normalized/top-level payload.
Sanitized payload excerpt
{
"event": "message",
"environment": {
"version": "2026.3.4",
"engine": "NOWEB",
"tier": "PLUS",
"platform": "linux/x64"
},
"payload": {
"hasMedia": true,
"media": {
"url": "https://waha.example/api/files/session/message-id.mp4",
"mimetype": "video/mp4"
},
"_data": {
"message": {
"videoMessage": {
"url": "https://mmg.whatsapp.net/...",
"mimetype": "video/mp4",
"gifPlayback": true,
"contextInfo": {
"statusSourceType": "GIF"
},
"gifAttribution": "GIPHY",
"accessibilityLabel": "GIF accessibility description",
"metadataUrl": "",
"videoSourceType": "USER_VIDEO"
}
}
}
}
}
Requested enhancement
For videoMessage.gifPlayback === true, expose normalized fields such as:
{
"mediaType": "video",
"isGif": true,
"gif": {
"attribution": "GIPHY",
"accessibilityLabel": "...",
"sourceType": "GIF",
"metadataUrl": "..."
},
"upstreamMediaUrl": "https://mmg.whatsapp.net/..."
}
The current payload.media.url points to WAHA's file endpoint, which may require an API key. For integrations that should not receive the WAHA API key, having the upstream WhatsApp media URL available in a normalized field would be useful.
Current workaround
Downstream code reads _data.message.videoMessage.gifPlayback, _data.message.videoMessage.url, gifAttribution, accessibilityLabel, and contextInfo.statusSourceType directly.
Environment
2026.3.4NOWEB(Baileys)messageSummary
Animated GIFs sent through WhatsApp arrive in NOWEB as
videoMessagewithmimetype: "video/mp4"andgifPlayback: true. This is probably expected from WhatsApp/Baileys, but downstream consumers need to dig into_data.message.videoMessageto preserve GIF semantics.It would be helpful if WAHA exposed the GIF-related metadata in the normalized/top-level payload.
Sanitized payload excerpt
{ "event": "message", "environment": { "version": "2026.3.4", "engine": "NOWEB", "tier": "PLUS", "platform": "linux/x64" }, "payload": { "hasMedia": true, "media": { "url": "https://waha.example/api/files/session/message-id.mp4", "mimetype": "video/mp4" }, "_data": { "message": { "videoMessage": { "url": "https://mmg.whatsapp.net/...", "mimetype": "video/mp4", "gifPlayback": true, "contextInfo": { "statusSourceType": "GIF" }, "gifAttribution": "GIPHY", "accessibilityLabel": "GIF accessibility description", "metadataUrl": "", "videoSourceType": "USER_VIDEO" } } } } }Requested enhancement
For
videoMessage.gifPlayback === true, expose normalized fields such as:{ "mediaType": "video", "isGif": true, "gif": { "attribution": "GIPHY", "accessibilityLabel": "...", "sourceType": "GIF", "metadataUrl": "..." }, "upstreamMediaUrl": "https://mmg.whatsapp.net/..." }The current
payload.media.urlpoints to WAHA's file endpoint, which may require an API key. For integrations that should not receive the WAHA API key, having the upstream WhatsApp media URL available in a normalized field would be useful.Current workaround
Downstream code reads
_data.message.videoMessage.gifPlayback,_data.message.videoMessage.url,gifAttribution,accessibilityLabel, andcontextInfo.statusSourceTypedirectly.