Stuck on an EventBridge rule that refuses to trigger for conversation.start events from Genesys Cloud. The setup is straightforward: a rule with an event pattern targeting the specific detail type, forwarding to a Lambda. Other event types like agent.state-change fire perfectly fine with the same rule structure, so the connection and permissions are solid. It’s just the conversation events that are ghosting me.
Here’s the pattern I’m using in the rule config:
{
"detail-type": [
"Conversation Started"
],
"source": [
"genesys.cloud"
],
"detail": {
"queueId": ["a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8"]
}
}
I’ve verified the queueId matches exactly what appears in the Genesys Cloud UI and API responses. I even tried broadening the detail section to just { "queueId": [ "*" ] } thinking maybe there’s a subtle mismatch, but that didn’t change anything. The Lambda logs show zero invocations when I start a test conversation in that queue.
I’ve checked the CloudWatch logs for the EventBridge service itself and don’t see any rejection errors. It’s just silent. Is there a specific nuance with how Genesys Cloud formats the detail payload for conversation events that I’m missing? I’ve been staring at the JSON schema in the docs for an hour and it looks standard. Maybe the detail-type casing is tricky? I’ve tried Conversation.Start, conversation.start, and the exact string from the docs. No luck.
Anyone else hit this wall? I’m about to dump the raw event from the Genesys Cloud event log into a separate test rule to see exactly what the payload looks like, but wanted to check if there’s a known gotcha with these specific event patterns first. It feels like I’m missing something obvious about the pattern syntax or the event source mapping.