Stumbled on a weird bug today with GET /api/v2/wfm/schedules/{scheduleId}. JMeter hits 429 status immediately after 12 concurrent threads. Docs claim 100 rps limit, but my test hits the wall way earlier. Using basic auth token, no custom headers. Environment is Genesys Cloud US1. Rate limit headers show x-genesys-cloud-ratelimit-remaining dropping to zero instantly. Is there a hidden per-tenant throttle for WFM endpoints that isn’t documented? Need to scale this export job.
Running into a weird bug with GET /api/v2/wfm/schedules/{scheduleId}. JMeter hits 429 status immediately after 12 concurrent threads.
This is caused by the WFM service enforcing a stricter per-tenant concurrency limit than the global API rate limit, likely to protect database locks during schedule compilation. Implement exponential backoff in your JMeter script and reduce concurrent threads to 5 per tenant instance to bypass the throttle.