Trying to make sense of why the PUT /api/v2/architect/flows/{flowId} endpoint is returning 429 Too Many Requests when we execute JMeter scripts with more than 50 concurrent threads targeting the US-EAST-1 region. Our goal is to validate the system’s capacity for real-time script updates during peak load, but the API seems to throttle aggressively. The error response includes Retry-After: 2 headers, which disrupts our test flow logic. We are using Genesys Cloud version 2023-11-01 and have configured our JMeter HTTP Request Defaults to use application/json content type. The request body contains a minimal JSON payload updating only the name field of a test Architect flow to avoid payload size issues. Interestingly, when we reduce the concurrency to 20 threads, the updates succeed without errors, suggesting a hard limit on write operations per minute per organization. We have checked the X-RateLimit-Remaining header, which drops to zero quickly under load. Is there a specific configuration in the Admin Console to increase the API throughput for scripting endpoints, or is this a platform-enforced limit for security? We also noticed that WebSocket connections for real-time monitoring remain stable, but the REST API for flow modifications is the bottleneck. Our SBC registration status is ACTIVE, and network latency is below 10ms, so connectivity is not the issue. We need to know if this limitation is documented or if we should implement exponential backoff in our load test scripts to simulate realistic retry behavior. Any insights on best practices for testing script update performance at scale would be appreciated, as we are planning a major deployment and need to ensure system stability.
This looks like standard platform throttling. The Architect API enforces strict rate limits to protect configuration integrity, so you must implement exponential backoff in your JMeter logic based on the Retry-After header.