We are hitting a wall with webhook delivery reliability. Our endpoint occasionally throws a 500 Internal Server Error due to upstream database locks. Genesys Cloud retries the delivery, but if the service is down for more than a few minutes, we lose the event data. The default retry mechanism isn’t enough for our compliance needs.
I want to build a sidecar service in C# that acts as a dead letter queue. The idea is to intercept the webhook, attempt to process it, and if it fails, store the payload in a local SQLite database with a retry schedule.
Here is the basic structure of the incoming webhook payload I’m parsing:
{
"id": "conv-123",
"type": "routing.conversation.updated",
"timestamp": "2023-10-27T10:00:00.000Z"
}
My concern is the handshake. If my sidecar service is slow, Genesys might mark the webhook as failed before I even get a chance to acknowledge receipt. I’m using HttpClient to send a 200 OK response immediately, then processing in the background. Is this the right approach? Or should I use the EventBridge integration to buffer these events instead of a custom HTTP endpoint? I’ve seen mixed results with EventBridge latency. Any code examples for handling the retry logic in .NET 6 would be appreciated.