Getting a steady stream of 500 Internal Server Error responses from the Genesys Cloud webhook delivery service. The endpoint is a simple Node.js Express handler listening for /api/v2/analytics/conversations/details/query events. The issue isn’t the payload parsing; it’s the downstream queue getting saturated. When the queue is full, the app crashes the process, Genesys sees the 500, and retries the same batch. This creates a thundering herd effect that takes down the server entirely.
I’m trying to implement a dead letter queue (DLQ) pattern directly in the webhook receiver to handle these failures gracefully. The goal is to acknowledge the webhook to Genesys (return 200) but push the payload to a local DLQ (using BullMQ with Redis) for async retry processing. However, I’m stuck on how to properly signal to the Genesys platform that the message was received but failed internally, versus a true success.
Here’s the current handler:
app.post('/webhook/conversations', async (req, res) => {
try {
const payload = req.body;
// This throws if Redis is down or queue is full
await dlqQueue.add('processConversation', payload, { attempts: 3 });
res.status(200).send('OK');
} catch (error) {
// Current behavior: returns 500, triggering Genesys retry
// Desired behavior: return 200, but log to DLQ for later retry
console.error('DLQ add failed:', error);
res.status(500).send('Internal Error');
}
});
If I return 200 in the catch block, Genesys stops retrying. But the data is lost if the DLQ add fails. Is there a way to use the SDK or API to mark a webhook delivery as “failed” without triggering an immediate retry loop? Or is the standard pattern to just swallow the error and rely on the DLQ’s own retry mechanism? The api/v2/webhooks docs don’t mention any “soft failure” status codes.