Trying to tighten up our EventBridge consumer logic. Currently, the subscription is firing for every conversation.end event across the entire organization, which is flooding our processing pipeline with noise. We only care about conversations ending in the “Support-Queue-Alpha” queue.
I’ve set up the subscription using the @genesyscloud/purecloud-platform-client-v2 SDK. The subscription endpoint is configured to send events to an SQS queue. The issue is that the filter parameter in the subscription request doesn’t seem to support deep path matching for the routing object’s queue property in the way I’m attempting.
Here’s the filter pattern I’m passing in the ConversationEventSubscription request body:
{
"filter": {
"type": "conversation",
"eventTypes": ["conversation.end"],
"routing": {
"queue": {
"id": "550e8400-e29b-41d4-a716-446655440000"
}
}
}
}
The API accepts this (200 OK), but the events arriving in SQS still contain conversations from other queues. I’ve verified the queue ID is correct by checking the routing.queue.id field in a raw event payload.
I’m looking at the Genesys Cloud documentation for EventBridge subscriptions, and it mentions that filters are applied at the source, but the syntax for filtering nested objects within the event payload isn’t clearly documented for the REST API vs the UI. Is the routing key even valid in the subscription filter payload, or do I need to handle this filtering client-side after receiving the event?
I’ve tried using the queue name instead of the ID, and I’ve tried nesting it under attributes as well, but nothing reduces the event volume. Just getting everything. Any insight into the correct JSON structure for the filter to scope it down to a single queue would be appreciated. I’m running out of ideas on how to prune this at the ingestion point rather than in the consumer code.