Looking for advice on handling OAuth 2.0 token refresh failures when simulating high-concurrency agent logins via the Genesys Cloud Platform API. I am running a load test using JMeter 5.6.2 to simulate 200 concurrent agents logging in every 60 seconds. The test hits the POST /api/v2/oauth/token endpoint. Initially, everything works fine. However, after about 10 minutes of sustained load, I start seeing a significant number of 401 Unauthorized responses. The error payload usually looks like this: {"code": "invalid_grant", "message": "The authorization code has been used or expired."}. This is confusing because I am generating fresh authorization codes for each user session in the test script. I am not reusing codes. The issue seems to correlate with the rate at which tokens are being issued versus the rate at which they are being validated by downstream services. I have checked the API rate limits documentation, but I am not hitting the standard 100 requests per second limit for this endpoint. The average response time spikes to over 2 seconds before the 401 errors start appearing. I am using the standard grant_type=authorization_code flow. Is there a known limitation on how quickly Genesys Cloud can issue new tokens for different users in a short window? Or is there a caching layer on the client side that I am missing in my JMeter configuration? I have tried adding a random delay between 500ms and 1s between requests, but the problem persists. I need to understand if this is a security throttling mechanism or a scalability bottleneck in the OAuth service. Any insights into how to structure the load test to avoid these false-positive failures would be appreciated. I want to ensure my load test accurately reflects production capacity without being skewed by authentication overhead.