Why does this setting in the Data Action webhook configuration seem to ignore the standard retry backoff when the ServiceNow instance returns a 429 Too Many Requests? We are pushing conversation metadata from Genesys Cloud to ServiceNow via a custom REST API endpoint, and the payload is relatively small. However, during peak hours in the Europe/London timezone, the ServiceNow side throttles the incoming requests.
The Genesys Cloud documentation suggests that webhooks have an internal retry mechanism for transient errors, but it appears that a 429 is being treated as a terminal failure rather than a retryable state. The logs show the initial POST fails, and subsequent attempts happen almost immediately, resulting in a cascade of failures.
Is there a specific header or configuration in the Data Action definition that forces Genesys to respect the Retry-After header sent by ServiceNow? We have verified that the OAuth token is valid and the endpoint is correct. The issue persists even after adjusting the timeout settings. Any insights into how the webhook engine handles rate-limiting responses from external systems would be appreciated. We need a robust solution that doesn’t require us to implement a queue on the ServiceNow side to absorb the burst.