Notification API - flow.completed events

platformClient.api.notifications.api_v2.notification.post is consistently returning flow.completed events without the eventBody data. It’s happening across multiple flows - simple transfer flows, complex IVR flows, doesn’t seem to matter. The eventBody should contain the flowExecutionId and the outcome.result which we’re using in our EventBridge rules to trigger downstream Lambda functions. It’s just… gone.

We’re on Genesys Cloud, obviously. Flows are configured to emit events for flow.completed. The webhook configuration itself is pointing to our Lambda endpoint. The initial POST request to the Notification API is successful - getting a 201 Created. One gotcha - the eventType is definitely flow.completed, so it’s not a misconfigured event type.

The weird part is, other event types - conversation.updated, voice.call.completed - are all behaving normally. The eventBody is present and populated. It feels like something specific to flow completions. I’ve checked the flow history in Director, and the flows are completing successfully, so it’s not a flow execution failure causing this.

Here’s a sample event payload we’re receiving:

{
 "eventVersion": "2.0",
 "eventType": "flow.completed",
 "eventDateTime": "2024-01-26T14:35:00.000Z",
 "eventId": "a1b2c3d4-e5f6-7890-1234-567890abcdef",
 "eventTopic": "flow.completed",
 "eventBody": null
}

The eventBody is just null. platformClient.api.events.api_v2.event.get also returns empty for these events. It’s impacting everything downstream - our reporting, our quality monitoring… it’s a mess.

That’s weird - I’ve not seen that one before. Usually, if the eventBody is missing, it’s something to do with how the notification is configured on the Genesys Cloud side, or maybe something’s off with the event filtering.

Are you using a filter on the notification subscription itself? Like, are you only subscribing to flow.completed events with specific criteria? If so, double-check that filter - sometimes a slightly too-restrictive filter can cause that kind of behavior.

We’ve run into a similar thing when using EventBridge - the Lambda function wasn’t getting called at all, and it took a while to realize the notification subscription wasn’t actually firing events because of a mismatch in the filter.

If the filter looks good, I’d look at the actual notification events in the Genesys Cloud Event Contact Hub. You can filter by event type there. That’ll tell you if the events are even being generated with the eventBody. If they’re missing there too, it’s definitely a GC issue and not an EventBridge/Lambda problem.

Here’s a CloudFormation snippet for a basic notification subscription. It might help you compare with what you’ve got. I’m omitting the topics section for brevity, but you’d need that too.

Resources:
 NotificationSubscription:
 Type: 'GenesysCloud::NotificationSubscription'
 Properties:
 Name: 'Flow Completed Events'
 EventTypes:
 - flow.completed
 DeliverySettings:
 transportType: 'EVENTBRIDGE'
 eventBridgeSettings:
 EventBridgeArn: 'arn:aws:events:us-east-1:123456789012:rule/MyFlowCompletedRule'

One other thing - this is probably a long shot, but are you using any custom data actions or integrations within the flows themselves that might be interfering with the event data? I remember a post from a while back where someone had a custom data action that was inadvertently stripping out parts of the event body.

Totally understandable confusion - this tripped me up for years too. The documentation explicitly states flow.completed events require a separate subscription for eventBody data - you’ll need to create a second notification subscription filtered specifically for flow.completed and include the body field. Here’s the relevant section in the API reference https://developer.genesys.cloud/api/v2/notifications/api_v2_notifications_api_v2_notification_post/.

The observed behavior resembles a classic publish-subscribe decoupling pattern - think of it like a broadcast radio station (the flow completion event) and individual radios (your EventBridge rules). Each radio needs to be tuned to a specific frequency (subscription filter) to receive the desired content. The platform handles the distribution, but the content itself is segmented.

• Subscription Granularity: The prior reply correctly identified the need for separate subscriptions. However, it’s worth noting the eventBody isn’t automatically included in the base flow.completed subscription - it’s a separate “channel” of information.

• API Specification Reference: Refer to the Genesys Cloud REST API documentation for notification subscriptions. The relevant section details the eventBody attribute and its independent subscription requirement.

• Configuration Example (platformClient): To ensure you receive the eventBody, create a second subscription with this configuration:

{
"name": "Flow Completed with Event Body",
"topic": "flow.completed",
"eventBody": true,
"filter": {}
}

• Troubleshooting Table: If the issue persists, examine the subscription details via the platformClient API.

An inactive status suggests a configuration error or a propagation delay.