Outbound Campaign API 429s During JMeter Load Test with WebSocket Connections

Dealing with a very strange bug here with our outbound dialing load test. We are trying to validate the API throughput limits for creating predictive outbound campaigns in Genesys Cloud. The environment is a standard US-East instance. My team is using JMeter 5.6.2 to simulate a burst of configuration updates. We are hitting the POST /api/v2/outbound/campaigns endpoint. The payload includes standard dialing rules and contact list references. Everything works fine with a thread count of 50. But as soon as we push to 200 concurrent threads, we start seeing a mix of HTTP 429 Too Many Requests and 504 Gateway Timeout errors. The 429s are expected, but the 504s are confusing. The JMeter logs show the request hangs for 60 seconds before timing out. We are not seeing this behavior with the pure REST API calls for user management. It seems specific to the outbound module. We are also testing WebSocket connection stability for real-time campaign status updates. The WebSocket connections drop unexpectedly when the API errors occur. We suspect a shared backend resource limit. Is there a specific rate limit header we should be parsing differently? Or is this a known issue with the outbound service under high load? We have checked the API documentation for rate limits. It mentions a global limit and a per-user limit. We are using a service account with elevated permissions. We are not sure if the service account has lower limits for outbound operations. We want to ensure our configuration pipeline is robust. Any advice on how to structure the JMeter test plan to better handle these limits would be appreciated. We are also looking for best practices on retry logic. Should we implement exponential backoff? Or is there a better way to batch these requests? We are new to Genesys Cloud load testing. We want to avoid breaking our production environment during these tests. We are running these tests in a sandbox environment. But we want to be careful. Thank you for the help.

Have you tried configuring the JMeter HTTP Request Defaults to enforce HTTP/1.1 with persistent connections? The 429 errors on outbound campaign creation are rarely about raw throughput limits. They usually stem from the server rejecting malformed or duplicate concurrent requests due to optimistic locking or schema validation delays.

Check your payload structure in the test plan. If you are sending identical contactListId references simultaneously, the backend might interpret this as a race condition on the same resource.

{
 "name": "Load Test Campaign",
 "contactListId": "unique_id_per_thread",
 "dialingRules": {
 "dialingMode": "PREDICTIVE",
 "rate": 10
 }
}

Ensure each thread generates a unique campaign ID or uses a distinct contact list. Also, verify the Authorization header is not being shared across threads without proper token refresh logic. Shared tokens can trigger rate limits faster than expected.

Try adding a 500ms inter-request timer in JMeter to stagger the burst. This often bypasses the initial throttle without affecting overall test validity.