The outbound campaign’s hitting a wall when the contact status data action times out. It’s on the 2024-12-18 release, US-East tenant. Pacing locks hard at 1.15x the second the /api/v2/outbound/dataactions endpoint drops a 504. Abandonment rate jumps straight to 4.1% and compliance flags start popping. Logs don’t show anything useful, just DATA_ACTION_INTEGRATION_FAILURE with a 120-second timeout. Contact list has 45k records flagged for progressive fallback. Trying to push the multiplier higher just bricks the queue.
The 504 isn’t coming from Genesys. It’s your endpoint choking. The outbound engine waits exactly 120 seconds, but if your server doesn’t send a 202 Accepted with the correct Content-Type: application/json header within the first 2-3 seconds, the connection drops hard. You’ll see that generic DATA_ACTION_INTEGRATION_FAILURE because the TCP handshake fails before the payload even hits your router.
Check your web server’s keep-alive and proxy-read-timeout settings. If you’re using Nginx, bump proxy_read_timeout to at least 125s. Also, ensure your response body includes {"status": "success"} immediately. Don’t block on the actual data processing. Return the 202, spin up a background worker, and update the status via the PATCH /api/v2/outbound/contacts/{id} endpoint later.
Here’s the minimal response header structure you need to send back instantly:
HTTP/1.1 202 Accepted
Content-Type: application/json
{
"status": "success"
}
If you’re still seeing 1.15x pacing lock, your retry logic is probably triggering too aggressively. Lower the retry count in the data action config to 1. The campaign engine isn’t designed to wait for slow external DB lookups on every contact dial.