Trying to understand the most robust pattern for handling persistent 5xx errors from Genesys Cloud webhook deliveries within a TypeScript consumer service. I am building a high-throughput event processor using the @genesys/cloud-sdk and express. When our downstream service times out, GC retries the webhook. If it fails again, we need to persist the payload to a dead letter queue (e.g., S3 or SQS) rather than letting it spin indefinitely.
Currently, my endpoint looks like this:
app.post('/webhook/gc', async (req, res) => {
try {
await processEvent(req.body);
res.status(204).send();
} catch (err) {
// Need logic here to detect if this is a final retry
console.error('Processing failed:', err);
res.status(503).send();
}
});
The issue is distinguishing between transient failures (where we should return 503 to trigger GC retry) and permanent failures (where we should log to DLQ and return 200 to stop retries). The webhook payload does not seem to include a retry count or attempt ID header in the standard x-genesys-* headers. Is there a recommended way to track retry state server-side, or should I implement a local cache based on id and timestamp to enforce a max-retry limit before moving to the DLQ? Environment: Node 20, TypeScript 5.4.