Hey everyone. I’ve hit a wall with my custom webhook consumer that listens to interaction.ring events from Genesys Cloud. The service is built on .NET 8 and sits behind an Application Gateway. When the downstream database gets busy, the endpoint returns a 503 Service Unavailable. I thought Genesys would just retry, but it seems to stop after a few attempts and I lose those ring events permanently. The logs show the 503 response, but no subsequent retry requests come through after about 30 seconds. Here is the basic controller setup:
[HttpPost("genesys/webhook")]
public async Task<IActionResult> HandleEvent([FromBody] JsonElement payload)
{
try
{
// Process logic
await _db.LogRingEvent(payload);
return Ok();
}
catch (Exception ex)
{
_logger.LogError(ex, "Failed to process ring event");
return StatusCode(503); // Thinking this triggers retry?
}
}
The problem is that returning 5xx seems to kill the retry chain faster than I expected. I need a way to handle these spikes without losing data. My thought is to implement a dead letter queue pattern locally. Instead of returning 503 immediately, maybe I should accept the event with a 200 OK, write it to a local Azure Service Bus queue, and let a background worker process it later. But then I lose the real-time nature of the ring event. Or should I just increase the timeout and return 503, hoping Genesys retries more aggressively? I’ve checked the docs on webhook delivery, but they don’t clearly state the exact retry schedule for 5xx errors versus 4xx. Is there a specific HTTP header or response body I need to send to tell Genesys “please retry this in 5 minutes”? Right now it feels like a black box. Any code examples of how you guys handle transient failures in webhook receivers? I’m worried about data loss if the DB goes down for 2 minutes. The event payload is small, just the interaction ID and agent ID. I don’t want to build a full retry service if there’s a simpler SDK or API config I’m missing. What’s the best practice here for .NET apps?