WhatsApp Interactive messages with media

[rudigiesler]

Currently if you try to send a message over WhatsApp that has both quick replies and an attachment, you get just the media with a caption, no interactive message with buttons/list.

The WhatsApp on-premise API has a header section, which supports media. This way you can have an interactive message with media, message body, and buttons/list. https://developers.facebook.com/docs/whatsapp/on-premises/reference/messages#interactive-object .

I know there has been some conversation around fully supporting headers, body, footer, etc. Is that the direction that you want to head towards, or would you accept a change to allow for the use case of quick replies + media being rendered as an interactive message with media header by courier, even as a stop-gap measure? It seems to me like that would be a minor change just affecting courier, where full header support would be a much larger change affecting many components.

[sreejith-yq]

@rowanseymour Bumping this up. You have already solved for the template message type where you both media(in header) and quick reply buttons are being supported in the same message. It would be great if you can solve for non-template interactive messages as well which WhatsApp now supports. Ideal if you can solve for the basic (media in header + text body + quick replies), then the list messages (quick reply buttons with descriptions). Adding support to WhatsApp flow and catalog features would also be nice to have.

The documentation for the WABA cloud API message object is here https://developers.facebook.com/docs/whatsapp/cloud-api/reference/messages/#message-object

I have been using direct Webhook calls to WABA API to get around the limitation but it is a non ideal fix.

[rowanseymour]

@sreejith-yq the challenge here is that this is fundamentally an omnichannel platform. We model a message as just text + attachments + quick replies because we can translate that into a form that makes sense over lots of different channel types (even then most messages we send are SMS and we ignore quick replies in that case). Where we've added channel specific things (e.g. WhatsApp templates, Facebook topics) it's out of necessity to make those channel types usable.

Frankly we'll probably need at some point to block users from using webhooks to send messages because that creates a whole new set of problems for us as it circumvents message queuing, billing etc. But we want to at least support most of the rich message features users need/want before doing that.

[sreejith-yq]

Thanks Rowan. This makes sense from a platform vision standpoint where you wouldn't want to make too many channel specific changes. But blocking the usage of webhooks for messaging would reduce the flexibility of the platform as well and it might be too tedious to keep track of all the features getting added to channels on a constant basis. Might I suggest adding a tab(call it advanced maybe) within the send message block where the flow dev could put in the body (header will remain the same for the channel) of the message to the channel so that Rapidpro can still track it as a message and all your message subroutines like queing and billing need not be disturbed.

[rowanseymour]

I thought about that but then we'll have messages in the system that other parts of the system (besides the courier sending code) don't understand (the UI, the loop detection, archiving etc). I think the sanest approach is to still model messages as text + attachments, but maybe for different channel types you can specify a preference as to how the attachments are used (sent as separate messages, used as a header etc).

[rowanseymour]

Or also for example you could specify that if the channel supports it, the final paragraph of the message text should be sent as a footer.