Step one: the downstream lambda needs to process wrap-up codes only when agents leave the Priority Support queue, so we’re trying to cut down the EventBridge traffic before it hits the function. We’ve got a filter pattern set up on the rule, but it’s still pushing every single conversation.end event regardless of the queue match. Here’s the filter JSON we’re passing to the CreateEventRule API call:
{
“source”: [“genesys-cloud”],
“detail-type”: [“conversation.end”],
“detail”: {
“conversation”: {
“queueId”: [“e3b7a1c2-8f4d-4a9e-b1c3-d5e6f7a8b9c0”]
}
}
}
The API returns a 200 OK when we create the rule, but the lambda logs show zero matches for that queue ID. We’ve double checked the UUID in the Genesys UI and it’s definitely correct. Step two: we tried expanding the filter to catch the routing object instead, since the queue usually lives there during the assignment phase. Swapped the detail path to detail.routing.queueId and re-deployed. Still nothing. The event payload structure from Genesys seems to nest the queue reference differently than the docs imply, or maybe EventBridge just doesn’t support nested object matching for this specific detail type.
We’re hitting the EventBridge API via the Python SDK on a London EC2 instance, so latency isn’t the issue. The raw event we’re seeing in CloudWatch looks like this:
{
“detail”: {
“conversation”: {
“id”: “a1b2c3d4-…”,
“routing”: {
“queue”: {
“id”: “e3b7a1c2-8f4d-4a9e-b1c3-d5e6f7a8b9c0”
}
}
}
}
}
So the path should technically be detail.conversation.routing.queue.id right? We updated the filter to match that exact hierarchy and pushed it through boto3.client(‘events’).put_rule(). The rule accepts it without complaints. Lambda still gets zero triggers for that queue. It’s picking up the default queue events fine though, which makes no sense. Step three: we added a catch-all prefix match on queueId using the prefix operator instead of an exact match array. Same result. The function just keeps getting flooded with general conversation ends. Are we missing a specific EventBridge syntax quirk for Genesys Cloud payloads, or does the conversation.end detail type just strip the routing context before it leaves the platform? We’ve got the raw CloudWatch logs ready to paste if needed. The filter pattern definitely isn’t evaluating the nested routing object correctly.