GC Webhook 500s and the Dead Letter Queue mystery

So my Azure Function keeps timing out on incoming Genesys Cloud webhooks. It’s a simple handler for conversation:wrap-up, but when the CRM is slow, the function hits its 10s limit. GC gets a 500 Internal Server Error back.

I read the docs: “If the target service returns a 5xx error, Genesys Cloud will retry the webhook delivery.” Okay, great. But after three retries, it just stops. No more attempts. Where is the payload going?

I checked the webhook configuration in the admin portal. There’s no “Dead Letter Queue” toggle. Just the URL, the headers, and the retry count (default 3).

POST /api/v2/webhooks
{
 "name": "crm-wraper",
 "uri": "https://myfunc.azurewebsites.net/api/webhook",
 "type": "web",
 "events": ["conversation:wrap-up"],
 "retryCount": 3
}

If the function crashes or times out, that data is gone. I need to catch these failures. Is there an API endpoint to configure a DLQ? Or do I have to handle the retry logic entirely in my .NET code by returning a specific status code that tells GC to back off? The docs mention “webhook delivery failure” but don’t explain where the failed JSON goes.

Feeling stuck on the error handling pattern here.

Cause: GC drops the ball after the retry limit hits. You’re losing data because there’s no fallback buffer.

Solution: Pipe the webhook into an Azure Service Bus topic first. Your function processes from the queue, so GC gets a 200 OK immediately and you never lose the event.

Service bus is the right move for decoupling, but don’t ignore the native DLQ. Check the webhook settings for deadLetterQueueEnabled. If it’s on, failed events land there. You can pull them via /api/v2/engagements/dlq or trigger a Lambda to reprocess. Saves you from building custom retry logic.