Looking for advice on handling rate limits when generating OAuth tokens for high-concurrency load tests.
We are running a performance validation suite using JMeter 5.6 against the Genesys Cloud US1 environment. The goal is to simulate a high volume of concurrent user logins to stress-test the authentication layer before a major deployment. The test plan involves 200 concurrent threads, each attempting to acquire an OAuth2 token via the /oauth/token endpoint using the client credentials flow.
The environment details are as follows:
- Platform: Genesys Cloud
US1 - Load Tool:
JMeter 5.6withHTTP Requestsamplers - Endpoint:
https://api.mypurecloud.com/oauth/token - Rate Limit Tier: Standard Enterprise
Within the first 10 seconds of execution, approximately 80% of the requests return HTTP 429 Too Many Requests. The response headers indicate the limit is being hit almost immediately, even though the total request rate is well below the documented general API limits. The Retry-After header suggests waiting 60 seconds, which breaks the concurrency model of the test.
We have tried adding a constant delay of 500ms between requests, but the 429 errors persist. The error payload shows:
{
"code": "tooManyRequests",
"message": "Rate limit exceeded"
}
Is there a specific rate limit bucket for the /oauth/token endpoint that is lower than the general API limits? We need to understand the exact threshold to adjust our JMeter thread group configuration. We are currently using a simple ramp-up of 10 seconds. Should we implement exponential backoff in the JMeter script, or is there a way to request a temporary rate limit increase for testing purposes?
Any insights on how to structure the load test to avoid hitting these auth limits while still validating concurrent user capacity would be appreciated. We want to ensure our token acquisition strategy is robust for peak load scenarios.