05-22-2024 07:04 AM
Hello,
we have an integration using Conversation API (WhatsApp channel) and we have subscribed to different callback types: delivery reports, conversations start, message inbound.
Furthermore we are subscribed also to events on templates update of Provisioning api.
All events are configured to being received to the same target url on our platform.
The question is: is there a way to detect the event type?
These events has very different payloads and now we implemented the detect like this:
if (body contains "message_delivery_report"){
//process events as delivery report
}else if (body contains "direction"){
//process inbound message
} else...
We are aware that this isn't a solid way to check the event type, but from what we see we can't bind event types in any other way.
Any suggestions on improvement?
For us having an header specifying the event type, for example, would be great (like shopify webhooks).
Thank you
Diana
Solved! Go to Solution.
05-22-2024 01:36 PM
Hello!
Thank you for reaching out! And thank you, Bipin, for providing these links!
In addition to the links Bipin provided, I recommend reviewing our Conversation API callbacks document. This document indicates that your approach may be the most effective for the Conversation API. There appear to be unique, top-level objects in the payload(s) to which you may map event types. You provided an example of this this in the snippet you shared for a delivery report callback:
if (body contains "message_delivery_report"){
//process events as delivery report
}
For the Provisioning API, there appears to be a top-level type
field in most callbacks. This type
field denotes the event that triggered the callback. For example, if one of your WhatsApp templates had its status updated, you can receive a callback with the type
field populated with WHATSAPP_TEMPLATE_STATUS_UPDATED
.
I'll reach out to get confirmation on all of this. In the meantime, please let us know if you have any other questions.
Thank you again!
05-22-2024 12:00 PM
Hello Diana,
Have you reviewed Sinch Developers portal (https://developers.sinch.com/) -- having Conversation API and WhatsApp documents?
Please review the following and see if this addresses your ask.
>> https://developers.sinch.com/docs/conversation/channel-support/whatsapp/message-support/#receiving-w...
Thanks.
Bipin Patel
05-22-2024 01:36 PM
Hello!
Thank you for reaching out! And thank you, Bipin, for providing these links!
In addition to the links Bipin provided, I recommend reviewing our Conversation API callbacks document. This document indicates that your approach may be the most effective for the Conversation API. There appear to be unique, top-level objects in the payload(s) to which you may map event types. You provided an example of this this in the snippet you shared for a delivery report callback:
if (body contains "message_delivery_report"){
//process events as delivery report
}
For the Provisioning API, there appears to be a top-level type
field in most callbacks. This type
field denotes the event that triggered the callback. For example, if one of your WhatsApp templates had its status updated, you can receive a callback with the type
field populated with WHATSAPP_TEMPLATE_STATUS_UPDATED
.
I'll reach out to get confirmation on all of this. In the meantime, please let us know if you have any other questions.
Thank you again!
05-23-2024 01:00 AM
Thank you, Biden. Unfortunately, we don't use WhatsApp-specific callbacks, but we activated the triggers:
As Sam said we can easily detect the event type between a WHATSAPP_TEMPLATE_APPROVED and WHATSAPP_TEMPLATE_REJECTED event because they have a top-level structure in common.
However, it's very difficult to distinguish a MESSAGE_DELIVERY event from a MESSAGE_INBOUND or a WHATSAPP_TEMPLATE_XXX event based on the payload because they have nothing in common.
I understand that these are very core functions, and my intention is to offer a suggestion for future improvement. For example, adding another custom header to the request like:
x-sinch-webhook-trigger=<trigger_type> //ie: MESSAGE_DELIVERY
could be a great help for detection and it shouldn't affect backward compatibility.
Thank you
Have a nice day!
Diana
05-23-2024 01:08 AM
Hello Diana,
Thank you for your suggestion. We will take your input with our R&D team for future improvement in the service.
Bipin Patel