Need some help troubleshooting why the OAuth 2.0 Client Credentials endpoint is returning 429 Too Many Requests when I try to simulate a high volume of concurrent API calls.
I am running a load test from Singapore using JMeter 5.6.2 to check the capacity of our authentication flow. The goal is to see how the platform handles a burst of token requests before the main business logic kicks in. I have set up a thread group with 100 concurrent users, each sending a POST request to https://api.mypurecloud.com/oauth/token. The payload includes the standard grant_type=client_credentials and our app credentials.
At low thread counts like 10 or 20, the requests complete successfully with a 200 OK and return the access token. However, as soon as I increase the concurrency to 50 or more, the majority of requests start failing with 429. The response headers include Retry-After: 1, but implementing a simple retry logic in JMeter just causes the test to hang or fail completely because the rate limit seems to be hit again immediately.
I am aware that there are general API rate limits, but I am not sure if there is a specific limit for the OAuth token endpoint itself. The documentation mentions standard platform limits, but nothing specific to authentication bursts. I have also checked the X-RateLimit-Remaining header in the successful responses, and it seems to be quite low, which is unexpected for a token endpoint.
Is there a recommended way to handle high-concurrency token requests? Should I be implementing a token caching strategy in my test setup, or is there a different endpoint I should be using for load testing purposes? Any advice on how to structure the JMeter test to respect these limits while still measuring throughput would be appreciated. I am trying to understand if this is a hard limit or if it can be adjusted for our use case.