Filtering EventBridge conversation.end events for a single queue ID

Setting up a webhook consumer to track call endings for our primary support queue. The goal is to keep the downstream Lambda lightweight by filtering events at the source. I’ve registered an event subscription targeting conversation.end, but it’s firing for every queue in the org. That’s way too much noise.

I tried adding a filter criteria in the subscription body using the queue ID. The docs mention filtering by conversation.queueId, but the event payload structure is tricky. Here’s the JSON I’m sending to POST /api/v2/analytics/events/subscription:

{
 "name": "QueueSpecificEnd",
 "type": "conversation.end",
 "filter": {
 "criteria": [
 {
 "field": "conversation.queueId",
 "op": "eq",
 "value": "8a204a8d-1234-5678-90ab-cdef12345678"
 }
 ]
 },
 "target": {
 "type": "webhook",
 "url": "https://my-endpoint.example.com/hook"
 }
}

The subscription creates successfully with a 200 OK, but the events still arrive for other queues. I checked the raw event payload in the logs, and the field looks like data.conversation.queueId, not just conversation.queueId. Maybe the filter path needs to be more specific? Or is this field not indexable for filtering in the subscription config?

I’ve also tried using data.conversation.queueId as the field name, but that resulted in a 400 Bad Request saying the field is invalid. I’m stuck between the filter not working and the field name being wrong. We need to stop processing irrelevant events before they hit the webhook. Anyone know the exact field path for queue-based filtering in event subscriptions? The documentation isn’t clear on nested object paths in the filter criteria.

The conversation.end event payload doesn’t include the queue ID at that stage. The contact has already been routed and potentially transferred, so the original queue context is gone from the JSON body. You can’t filter on conversation.queueId in the subscription criteria because the field simply isn’t there when the event fires.

You’ll need to filter on conversation.initialQueueId if you only care about where the contact first landed. Here’s the correct criteria structure for the subscription update:

{
 "criteria": [
 {
 "field": "conversation.initialQueueId",
 "operator": "eq",
 "value": "your-queue-id-here"
 }
 ]
}

If the contact gets transferred out of that queue before ending, this filter won’t catch it. That’s usually the trade-off. If you need to track every exit regardless of transfer history, you’re stuck pulling the full stream and filtering in your Lambda. It’s heavier, but it’s the only way to get the complete picture. EventBridge subscriptions are pretty strict about what fields are available per event type.