Why does this setting in our Architect flow trigger a 429 Too Many Requests error almost immediately when JMeter starts its ramp-up phase? We are testing a custom Data Action that queries an external REST endpoint for customer data. The flow is simple: Receive Call → Get Customer Data (Data Action) → Route to Agent.
We are using JMeter 5.6.2 with the HTTP Request sampler. The target endpoint is /api/v2/architect/dataactions/{id}/execute. We have configured the JMeter test plan with 200 threads, a ramp-up period of 30 seconds, and a loop count of 10. The goal is to simulate 200 concurrent calls initiating the data lookup.
HTTP 429 Too Many Requests
The error occurs within the first 5 seconds of the test. The response header includes Retry-After: 2. We have checked the Genesys Cloud developer documentation regarding API rate limits. The limit for Data Actions is listed as 100 requests per second per organization. With 200 threads ramping up over 30 seconds, the theoretical peak is around 6-7 requests per second per thread, which should be well within limits if distributed evenly. However, the 429s start appearing when the total concurrent requests hit roughly 15.
We are using a valid OAuth2 token for authentication. The token is refreshed every 50 minutes. The external REST endpoint is responding in under 200ms, so the bottleneck seems to be on the Genesys Cloud side. We have tried adding a constant timer of 100ms in JMeter, but the 429s still appear.
Is there a specific limit on concurrent Data Action executions per flow? Or is there a setting in the Data Action configuration that we are missing? We need to understand if this is a hard limit that cannot be exceeded or if there is a way to optimize the flow to handle higher concurrency. Our production environment expects to handle up to 500 concurrent calls, so this is a critical issue for our capacity planning. Any insights or configuration changes would be greatly appreciated.