If you are only receiving conversation.end events and not conversation.start, please verify the following configuration items:
- Topic Subscription: Ensure your WebSocket subscription explicitly includes
v2.conversations.{id}.start. The wildcard v2.conversations.* does not exist.
- Channel Health: As documented in the Resource Center, notification channels expire after 30 minutes. If your channel expired and you re-established it, you must re-subscribe to all topics.
- Event Ordering: The
start event fires before the conversation is routed. If your filter includes a queue ID, you may be inadvertently dropping it.
We ran into this exact issue when building our Microsoft Teams presence sync.
Our PowerShell script listened for conversation.start to toggle the Teams user status to ‘Busy’. But the webhook was only delivering conversation.end. It turned out our Azure API Management gateway was silently dropping the start events because the payload was smaller than the minimum content-length threshold we had configured.
I think this is happening to me too, but I honestly don’t understand what a webhook is.
I inherited this org 6 months ago. I think the previous admin set something up in the Integrations tab, and I can see a URL pointing to some external server. But I have no idea if it is working or broken. Is there a way to test it without calling a real customer?