So I’m seeing a very odd bug with the WFM schedule update API throwing excessive 429 Too Many Requests errors during load testing. The setup involves JMeter 5.6.2 with a thread group ramping up to 50 concurrent users over 30 seconds, hitting POST /api/v2/wfm/userschedulesegments. The target environment is Genesys Cloud in ap-southeast-1.
The strange part is that the 429s start appearing almost immediately after the ramp begins, even though the total request count per second is well below the documented global limit. The JMeter log shows the retry logic kicking in, but the requests fail with the same rate limit error repeatedly. The error response body indicates the limit is hit for the specific tenant scope, not just a generic global cap.
Is there a specific per-endpoint throttle for schedule segments that isn’t clearly documented? Or could this be related to how the WebSocket connections are handled in the background during high concurrency? The test stops cleanly if the concurrency is capped at 10 threads, so it seems tied to the connection density rather than raw throughput. Any insights on tuning the JMeter HTTP Request Default settings to handle this better?