Can’t get this config to load properly… We are trying to validate the Genesys Cloud Workforce Engagement Management API endpoints under high concurrency using JMeter 5.6. The specific goal is to simulate bulk schedule updates for 500 agents via POST /api/v2/wfm/scheduling/schedules. When we hit 50 concurrent users, the response time spikes and we start receiving HTTP 429 Too Many Requests errors. The standard documentation mentions rate limits, but it is unclear if the limit applies per organization or per API key during a load test. We are using the same access token for all threads in JMeter to isolate the throughput capability. The error payload includes a Retry-After header but the value is inconsistent, sometimes 1 second, sometimes 5 seconds. This makes it difficult to configure the JMeter timer correctly for a realistic stress test. We are not seeing any 500 errors, just the 429s. Is there a way to increase the rate limit threshold for testing purposes, or is there a specific header we need to include to handle the retry logic programmatically in our script? The environment is a production instance in us-east-1. We need to know the exact ceiling for this endpoint before we proceed with the migration cutover plan.
The best way to fix this is to implement exponential backoff in JMeter using the HTTP Request Defaults controller to respect the Retry-After header. WFM endpoints enforce strict per-org limits, so staggering requests is mandatory for 500+ agent updates.