Can anyone clarify the rate limits for Workforce Management APIs in Genesys Cloud US1?
Running JMeter 5.6 with 100 concurrent users against GET /api/v2/wfm/schedules. The endpoint returns HTTP 429 Too Many Requests after roughly 50 requests per minute. The response header shows X-RateLimit-Remaining: 0 and Retry-After: 15. This happens even when using valid OAuth2 tokens and proper pagination. The load test script sends requests with 1-second intervals between each user’s request cycle. Each request includes the Accept: application/json header and valid query parameters for date range filtering. The test environment is a production US1 instance with standard API limits. The goal is to validate system behavior under concurrent load for schedule retrieval operations. The JMeter thread group is configured with a ramp-up period of 10 seconds and a loop count of 5. Each thread uses an HTTP Request sampler with the correct endpoint URL and authentication headers. The test fails consistently at the same threshold, suggesting a hard limit rather than a transient network issue. The Retry-After value varies between 10 and 30 seconds, making it difficult to implement a consistent retry logic in the test script. The documentation mentions rate limits but does not specify exact values for WFM endpoints. The test results show a 95% error rate when exceeding 50 requests per minute per tenant. The remaining 5% of requests succeed, indicating that the limit is not absolute but probabilistic. The error logs capture the full response body and headers for analysis. The test environment has no custom rate limiting configurations applied. The standard GC API rate limits apply. The goal is to determine the exact threshold and implement proper backoff strategies in the load test script. The current approach uses a fixed delay, which is inefficient. The test results are consistent across multiple runs. The environment details include JMeter 5.6, Java 11, and Genesys Cloud US1 region. The API version is v2. The authentication method is OAuth2 client credentials. The scope includes wfm:schedule:read. The test data includes valid schedule IDs and date ranges. The expected behavior is to handle rate limits gracefully without test failure. The actual behavior is test failure due to unhandled 429 errors. The question is how to properly handle these limits in a load testing scenario. The documentation suggests using exponential backoff, but the exact parameters are unclear. The test script needs to be adjusted to respect the Retry-After header. The current implementation ignores this header and retries immediately, leading to more 429 errors. The goal is to find a reliable way to simulate realistic load while respecting API limits. The test results will be used to validate system capacity and performance under load. The environment is stable and the issue is reproducible. The request is for guidance on best practices for handling rate limits in JMeter scripts for Genesys Cloud APIs.