Trying to understand why we are hitting rate limits on the Architect API when we are just publishing a single flow definition multiple times in parallel. We are running a JMeter script to simulate a high-churn environment where developers might accidentally trigger multiple publish events. The goal is to see how the platform handles concurrent write requests to the /api/v2/architect/flows/{id} endpoint.
The setup involves a simple IVR flow with a few menu nodes and a transfer action. We are not making any changes to the logic, just hitting the publish endpoint with different flow IDs to simulate a batch deployment scenario. The JMeter thread group is configured with 50 concurrent users, each executing a loop of 10 iterations. We are using the standard OAuth2 bearer token authentication.
Here is the environment details:
- Genesys Cloud org: US-East-1
- API Client SDK: Java 5.3.2
- JMeter Version: 5.6.2
- Concurrent Threads: 50
- Ramp-up Period: 10 seconds
- Loop Count: 10
After about 30 seconds into the test, we start seeing a mix of responses. The majority are 200 OK, but roughly 15% of the requests return 429 Too Many Requests. The response headers include Retry-After: 2, which suggests the server is throttling us. However, since each request is targeting a unique flow ID, I would expect these operations to be independent and not hit a global rate limit so quickly.
We checked the API documentation for rate limits, but it mentions limits per organization and per resource. Since we are spreading the load across 500 unique flow IDs, it feels like we should be under the threshold. Is there a hidden global throttle for publish actions? Or is the issue related to how the Architect service processes background compilation tasks?
Any insights on how to structure our load test to avoid these false positive rate limits would be appreciated. We want to ensure our CI/CD pipeline can handle batch deployments without failing due to transient throttling.