Why is this setting causing 429s on Script Data Actions?
I am trying to validate our script performance under load using JMeter. The goal is to simulate 50 concurrent agents triggering a specific data action within an Architect flow. The data action calls a simple internal API to fetch customer tier info. It works fine with 10 threads but fails consistently at higher concurrency.
Here is the environment setup:
- Region: ap-southeast-1 (Singapore)
- JMeter Version: 5.6.2
- Thread Count: 50
- Ramp-up: 10 seconds
- Loop Count: 100
- Endpoint: /api/v2/architect/data-actions
The error happens specifically on the POST request to execute the data action. The response is a 429 Too Many Requests with a retry-after header of 2 seconds. I have checked the standard API rate limits documentation and it says the limit is 100 requests per second for this endpoint. With 50 threads and a 1-second delay between iterations, the theoretical rate is 50 rps, which should be well within the limit.
I have also verified the OAuth token refresh logic. Tokens are being refreshed every 55 minutes to avoid expiration during the test. The 429s start appearing after about 2 minutes into the test run. It seems like there might be a hidden throttle based on concurrent WebSocket sessions or maybe a limit on active data action executions per organization.
Has anyone else seen this behavior when load testing data actions? I am wondering if there is a specific configuration in the Architect flow that needs adjustment to handle higher throughput. The script itself is very simple, just a single data action node followed by a set variable node. No complex logic or external integrations involved. Just pure API calls to the Genesys Cloud platform.
Any insights on how to bypass this limit or if I am misunderstanding the rate limiting mechanism would be appreciated. I need to ensure our scripts can handle peak hour volumes without throttling errors impacting agent workflows.