We’re hitting a wall with webhook reliability for conversation:updated events. Our consumer endpoint is sitting behind an ALB and occasionally throws a 502 Bad Gateway during high load spikes. Genesys Cloud retries the delivery, but the retry window seems aggressive, and we’re dropping events when the backend is genuinely busy processing the previous batch.
I’ve looked into the webhooksApi.updateWebhook method to adjust the retry policy, but the SDK models for Webhook don’t expose fine-grained control over the backoff strategy or a dead letter queue endpoint directly. The standard retry config only allows setting the number of retries and the interval, which isn’t enough for our use case. We need a way to persist failed payloads if the consumer is down for more than the max retry duration.
Here’s the current setup in our TypeScript service:
const updateWebhook = async (webhookId: string) => {
const body = {
...existingWebhook,
retryCount: 5, // Max allowed?
retryInterval: 60, // Seconds
// No DLQ property available in the schema
};
await webhooksApi.updateWebhook(webhookId, body);
};
Is there a hidden field or a different API endpoint to attach an S3 bucket or SQS queue as a fallback when all retries are exhausted? The documentation mentions “delivery failure handling” but doesn’t specify how to implement it via the API. We’re considering building a sidecar that listens to a raw webhook endpoint and pushes to a queue, but that feels like reinventing the wheel. Does the platform support a native DLQ pattern for webhooks, or is the only option to handle persistence logic entirely within the consumer and return 200 immediately to stop retries?