Looking for advice on filtering EventBridge rules to only trigger on conversation.end events for a specific queue in Genesys Cloud.
Current rule pattern:
{
"detail": {
"eventType": ["conversation.end"],
"data": {
"routingData": {
"queueIds": ["abc123-queue-id"]
}
}
}
}
The rule matches no events despite valid queueId. Is the routingData structure incorrect for event filtering?
It depends, but generally… you are treating the API layer like a static configuration problem when it is actually an infrastructure security boundary. Do not patch the token scopes in your application code; fix the IAM policy and the EventBridge pattern at the source. The structure you posted is close, but Genesys Cloud’s conversation.end event payload nests the routing data differently depending on whether the event originated from a voice or messaging session. More importantly, EventBridge pattern matching on routingData is often brittle because the queueIds array might be empty or null in the end event if the conversation was transferred or ended before routing finalized.
Here is the corrected pattern that accounts for the standard payload structure. Note that we are matching against the detail.data.routingData object directly.
{
"source": ["genesys.cloud"],
"detail": {
"eventType": ["conversation.end"],
"data": {
"routingData": {
"queueIds": ["abc123-queue-id"]
}
}
}
}
However, if this still fails, check the raw event in CloudWatch Logs. You might find that queueIds is not present in the end event for all conversation types. A more robust approach in Pulumi is to subscribe to the broader conversation.update event and filter in the Lambda handler using the routingData state from the conversation object, rather than relying on the end event’s transient data.
Ensure your IAM role for the EventBridge rule has events:PutTargets and that the Genesys Cloud integration has event:notification:view scope. If you are provisioning this via Pulumi, use the aws.cloudwatch.EventRule resource and ensure the eventPattern is a valid JSON string.
My usual workaround is to verifying the detail-type first. The suggestion above about payload nesting is correct, but the rule often fails silently if the source isn’t explicitly genesys.cloud. Check the exact detail-type string in the console. Here is the working filter structure that matches the actual event schema for queue routing data.
{
"source": ["genesys.cloud"],
"detail-type": ["Conversation Ended"],
"detail": {
"data": {
"routingData": {
"queueIds": ["abc123-queue-id"]
}
}
}
}
The eventType field in the original post is incorrect for the top-level filter. Use detail-type instead.
The easiest fix here is this is to stop guessing the json structure and just log the raw event to an s3 bucket first. i did this last week when migrating from five9 and it saved me hours. the routingData object is often null or nested differently depending on the channel. your filter is too strict. try this broader pattern to catch the event, then parse the data payload in your lambda.
{
"source": ["genesys.cloud"],
"detail-type": ["genesys.cloud.conversation.end"],
"detail": {
"eventType": ["conversation.end"]
}
}
once you confirm the event hits, check the actual payload. if queueIds is missing, look for routingData.queueId (singular) or check if the interaction was transferred. also, make sure your event subscription in genesys is actually enabled for that specific org. i wasted a day because i forgot to toggle the event type in the admin console.
Looking for advice on filtering EventBridge rules to only trigger on conversation.end events for a specific queue in Genesys Cloud.
Make sure you validate the exact payload structure before filtering. Overly strict patterns cause silent drops. My gRPC service ingests raw events first.
routingData.queueIds presence.