Why does this setting cause immediate 429 Too Many Requests errors when hitting the /api/v2/outbound/campaigns endpoint? The rate limit header indicates a quota of 100 requests per minute, but the JMeter plan is only sending 25 requests per second. The 504 timeout follows shortly after the initial 429s. Need help tuning the concurrent call volume to stay within the platform_api limits.
The 429s stem from exceeding the per-second API limit, not just the per-minute quota. Implement exponential backoff in your JMeter script to manage request bursts.
Ah, yeah, this is a known issue with how JMeter handles concurrent thread initialization against Genesys Cloud’s strict burst limits.
The problem is not the average throughput, but the instantaneous spike. When 500 threads ramp up in 10 seconds, JMeter attempts to open all connections simultaneously. Genesys Cloud API gateway sees a massive burst of new WebSocket handshakes and API calls in the first 1-2 seconds, which exceeds the per-second rate limit (often ~10-20 req/sec for outbound endpoints), even if the minute-level quota is technically safe. The 429 is a burst protection mechanism. The subsequent 504 occurs because the client is stuck retrying or waiting for responses from timed-out requests that were never processed.
To fix this, you must flatten the load curve. Do not use a simple ramp-up. Use the “Constant Throughput Timer” or “Concurrency Thread Group” plugin to enforce a steady, flat line of requests. Also, ensure you are reusing HTTP connections. Here is a basic JMeter configuration snippet using the Throughput Controller:
<!-- Use Constant Throughput Timer -->
<ConstantThroughputTimer>
<boolProp name="ConstantThroughputTimer.useRandomDelay">false</boolProp>
<stringProp name="ConstantThroughputTimer.throughput">1200</stringProp> <!-- 20 req/sec * 60 sec -->
</ConstantThroughputTimer>
<!-- Or in Concurrency Thread Group properties -->
<property name="TargetLevel">500</property>
<property name="RampUp">60</property> <!-- Increase ramp up significantly -->
<property name="Steps">10</property>
Adjust the ramp-up time to at least 60 seconds to allow the connection pool to stabilize. If you see 429s, reduce the target concurrency by 10% and add a 50-100ms think time between requests. The API documentation states the limit is 100/min, but the hidden burst limit is much lower.