Looking for advice on handling HTTP 429 Too Many Requests errors when triggering a custom Data Action from an Architect flow under high concurrency.
I am running a load test using JMeter to simulate 200 concurrent interactions hitting a specific Architect flow in the Asia/Singapore region. The flow includes a Data Action step configured to call an external REST endpoint via the Genesys Cloud Data Action integration. Under normal load (below 50 concurrent users), the Data Action executes successfully, and the response is returned to the Architect flow without issues. However, as soon as the concurrent volume spikes above 100, the Data Action step consistently fails with a 429 status code, even though the external endpoint is not rate-limited and can handle the load independently.
The error response from the Genesys Cloud platform indicates that the request to the Data Action has been throttled. I have checked the API documentation and see that there are rate limits for platform APIs, but I am unsure if Data Actions share the same quota as standard REST API calls or if they have a separate limit. The JMeter test plan is configured to ramp up users over 10 seconds and hold the load for 2 minutes. The error occurs almost immediately after the ramp-up phase completes.
Here are the details of the environment:
- Genesys Cloud Region: APAC (Singapore)
- JMeter Version: 5.4.1
- Concurrent Users: 200
- Data Action Type: HTTP POST to external service
- Architect Flow Version: Latest
I have tried adding a small delay (100ms) before the Data Action step in the Architect flow, but this only reduces the frequency of the errors, it does not eliminate them. I also verified that the external endpoint is returning 200 OK for all requests when called directly from JMeter, so the issue seems to be within the Genesys Cloud platform’s handling of the Data Action invocation.
Has anyone encountered similar rate limiting issues with Data Actions during load testing? Is there a way to increase the rate limit for Data Actions, or is there a recommended pattern to handle high-volume invocations without hitting the 429 limit? Any guidance on configuring the JMeter test plan or Architect flow to mitigate this would be appreciated.