Looking for advice on handling OAuth token refresh rate limits when simulating massive concurrent agent logins via JMeter.
We are running load tests from our Singapore office to validate the platform’s capacity during peak shift changes. The scenario involves 500 virtual users attempting to authenticate simultaneously using the /api/v2/oauth/token endpoint with the client credentials grant.
The issue arises not during the initial login, but when the access tokens expire and the clients attempt to refresh them. We are seeing a cascade of 429 Too Many Requests errors specifically on the refresh token exchange. The JMeter logs indicate that the X-RateLimit-Remaining header drops to zero almost instantly once the refresh wave hits.
Here is the relevant error snippet from the response:
{
"message": "Too Many Requests",
"status": 429,
"errors": [
"Rate limit exceeded for client_id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
]
}
I have reviewed the documentation on rate limits, but it is unclear if the limit is per client ID, per IP, or per tenant. Since all 500 users are using the same client ID in our test setup, we are hitting the ceiling hard. Is there a recommended pattern for staggering token refresh requests in a high-volume environment? Should we be implementing exponential backoff on the client side, or is there a way to configure higher throughput limits for this specific endpoint in Genesys Cloud?
Currently, the test fails completely after the first wave of refreshes because the clients cannot obtain new tokens, causing the simulated agents to drop off the platform. This feels like a bottleneck that would affect real-world stability if many agents log off and on at the same time. Any insights on best practices for managing OAuth refresh rates at scale would be appreciated. We are using the latest version of the Genesys Cloud API as of this month.