I’m trying to figure out why the Architect API is throttling requests during a controlled load test. The environment is a Genesys Cloud tenant in US-East. The load test uses JMeter 5.5 to simulate a sudden spike in flow updates via the API. The script is configured to hit the endpoint POST /api/v2/architect/flows with a custom flow definition payload. The goal is to measure how the platform handles bulk configuration changes during peak hours, specifically around 2 PM EST when internal admin activity is also high.
The test starts with 50 concurrent threads. Each thread sends a unique flow definition. The first 30 requests complete successfully with 200 OK. Immediately after, the responses shift to 429 Too Many Requests. The response headers include Retry-After: 1 and X-Rate-Limit-Remaining: 0. This happens consistently every time the test runs, even when executed outside of business hours. The JMeter log shows the error occurring within milliseconds of the 30th request. The payload size is approximately 15KB per request. No WebSocket connections are involved in this specific test, only REST API calls.
The documentation mentions rate limits for architect endpoints but does not specify the exact burst capacity for flow creation. Is there a specific limit on the number of flow creations per second per tenant? The current behavior suggests a hard limit of roughly 30 requests per second. This limit is blocking the ability to validate system stability under high configuration load. The team needs to know if this is a configurable limit or a fixed platform constraint. Adjusting the JMeter ramp-up time to spread requests over 10 seconds avoids the 429 errors, but this does not reflect the real-world scenario where bulk imports might trigger rapid sequential calls.
How can we accurately determine the maximum sustainable throughput for POST /api/v2/architect/flows without triggering rate limiting, and is there a way to increase this limit for load testing purposes?