Just noticed that the Genesys Cloud WFM Schedule Optimization endpoint is behaving unexpectedly during our recent load testing cycle. We are trying to validate the API throughput for bulk schedule generation in the Singapore region, but the system seems to hit a hard wall much faster than the documented rate limits suggest.
The test setup involves JMeter 5.6 running from a local instance in SG. We are targeting the /api/v2/wfm/scheduling/optimizations endpoint with a POST request containing a valid scheduling request payload. The goal is to simulate a spike in schedule generation requests similar to what we might see during a major holiday planning event.
Here are the steps to reproduce the issue:
- Initialize a JMeter test plan with a Thread Group set to 50 concurrent users.
- Configure each thread to send a POST request to the WFM optimization API with a unique scheduling ID and standard shift constraints.
- Set the ramp-up period to 10 seconds to simulate a sudden burst of requests.
- Monitor the response codes and latency in the View Results Tree listener.
After approximately 15 seconds of execution, the majority of requests start failing with a 429 Too Many Requests error. The response headers indicate a retry-after value of 60 seconds, which is significantly impacting our ability to complete the load test within a reasonable timeframe. Interestingly, if we reduce the concurrency to 10 threads, the requests succeed consistently, but scaling up to 20 or more triggers the rate limiting again.
We have checked the API documentation and the rate limits listed there, but they seem to allow for higher throughput than what we are observing. Is there a specific limit for the WFM optimization API that is not clearly documented? Or is there a configuration setting in the Genesys Cloud admin portal that we might have missed? Any insights on how to handle this during high-volume load tests would be appreciated.