API 429s on /api/v2/architect/flows during JMeter load test

Can anyone clarify why I am hitting rate limits on the Architect API?

Context:
Running a basic load test on our Genesys Cloud instance (US1). The goal is to validate API throughput for flow updates. Using JMeter 5.6.2. Script sends POST requests to /api/v2/architect/flows. Concurrency set to 50 virtual users. No complex logic, just updating a simple flow ID.

Question:
Errors start appearing after 30 seconds. Response is HTTP 429 Too Many Requests. Headers show ‘x-ratelimit-reset’ time. I checked the documentation for API rate limits. The limit for this endpoint seems high enough for 50 users. Is there a specific burst limit I am missing? Or is the WebSocket connection handling affecting this? My script uses standard HTTP sampler. No custom headers. Token refresh is handled correctly, no 401s. Just 429s. I need to understand if this is a platform restriction or a test configuration issue. Any advice on JMeter settings to handle this?

This has the hallmarks of a standard rate limit trigger on the Architect API. The endpoint enforces strict quotas per organization, not just per client ID. Check the X-RateLimit-Reset header in your response to implement proper backoff logic. See the official documentation here: https://developer.genesys.cloud/api-docs/architect/flows. Adjust your JMeter thread group pacing accordingly.

Check your JMeter HTTP Request Defaults for connection pooling and ensure the Keep-Alive header is enabled to prevent TCP overhead from skewing the rate limit counter.

• WebSocket connection limits
• API rate limits
• Call capacity planning