Dealing with a very strange bug here with our Genesys Cloud predictive outbound campaign integration where the ServiceNow REST API endpoint is returning 429 Too Many Requests responses during peak dialing hours. The architecture uses a Data Action triggered by the ‘Call Answered’ event in the Architect flow to push contact disposition and interaction details to a specific SNOW table via POST. We have configured the webhook timeout to 30 seconds as per best practices to prevent silent drops, but the issue persists because the GC Data Action engine seems to be retrying the failed request immediately upon receiving the 429 status code from the ServiceNow instance. This creates a feedback loop where the SNOW rate limiter blocks the requests, GC retries, SNOW blocks again, and the queue backs up significantly. The error logs in the Genesys Cloud Data Action history show HTTP 429: Rate Limit Exceeded followed by a 504 Gateway Timeout after the 30s window, but the actual root cause is the aggressive retry logic not respecting the Retry-After header sent by ServiceNow. I am cross-referencing the Genesys Cloud Data Action documentation which mentions standard HTTP status code handling, but it lacks specific details on how the engine processes rate-limiting headers from downstream REST APIs. The environment is running the latest Genesys Cloud release in the eu-west-1 region, and the ServiceNow instance is configured with a rate limit of 100 requests per minute per IP. The outbound campaign is currently set to dial 500 contacts per hour, which theoretically should not exceed the rate limit if the success rate is high, but the initial burst of answered calls is causing the spike. I need to understand if there is a way to configure the Data Action to pause or back off when a 429 is received, or if we need to implement an intermediate queueing mechanism to smooth out the request rate to the ServiceNow endpoint. The current behavior is causing significant latency in updating the contact records, which impacts our compliance reporting and agent visibility into previous interactions. Any insights on configuring the Data Action retry policy or handling rate limits effectively in this integration pattern would be appreciated. The goal is to ensure reliable data synchronization without overwhelming the downstream ServiceNow API gateway.