migrating our event processing pipeline to use Genesys Cloud EventBridge subscriptions for real-time state changes. The goal is to ensure that every agent state change is captured and processed by our internal microservices without data loss.
The issue arises when the downstream consumer service experiences a temporary outage or returns a 5xx status code. Genesys Cloud will retry the delivery for a specific window, but if the service remains unavailable, the events are eventually dropped. We need a mechanism to capture these failed events for later processing, essentially a dead letter queue (DLQ) pattern.
We have explored the EventBridge API documentation and found that we can define a subscription object with a target configuration. However, there is no explicit deadLetterQueue field in the standard post or put request payloads for /api/v2/analytics/events/subscriptions.
We attempted to configure a secondary target using the http target type, but the API schema does not seem to support conditional routing based on delivery success or failure. The current implementation looks like this:
{
"name": "AgentStateChangeSubscription",
"description": "Captures agent state changes",
"events": [
"agent.state.change"
],
"target": {
"type": "http",
"url": "https://our-internal-service.example.com/webhook"
}
}
When the endpoint returns a 503 Service Unavailable, Genesys retries according to its internal policy, but we have no visibility into the failed attempts after the retry window expires. We are looking for a code-level solution or an API configuration that allows us to route these failed events to a separate endpoint or a queue service like AWS SQS or Azure Service Bus.
Has anyone implemented a custom retry mechanism or a DLQ pattern using the EventBridge API? We are considering writing a wrapper service that accepts the initial webhook and manages its own retry logic with a DLQ, but we want to confirm if there is a native way to handle this within the Genesys Cloud platform first. The Terraform provider for CX-as-Code does not expose any fields for DLQ configuration either, which suggests this might not be a supported feature natively.