Just noticed that the user provisioning endpoint is hitting rate limits way faster than the documentation suggests for our specific tier.
We are running a baseline load test to validate the API throughput for bulk user onboarding in our BYOC Edge environment. The goal is to simulate a scenario where HR system updates trigger simultaneous user creation and configuration updates. I expected the standard 5 requests per second limit per endpoint, but the 429 errors are appearing almost immediately after the test thread group starts ramping up, even when the actual request rate is well below that threshold.
Here is the current setup:
- Tool: JMeter 5.6.2
- Environment: Genesys Cloud BYOC Edge 24.1.0 (Asia/Singapore)
- Endpoint: PUT /api/v2/users/{userId}
- Payload: Standard user object with profile, routing, and team assignments (~1.5KB JSON)
- Threading: 10 threads, ramp-up 5 seconds, loop count 100
The error response is a standard 429 Too Many Requests. The Retry-After header suggests waiting, but the issue is that the throttling seems inconsistent. Sometimes it allows 3 requests through, then blocks the next 10. Other times it blocks immediately. This is making it hard to establish a reliable baseline for our capacity planning.
I have checked the response headers and see x-ratelimit-remaining: 0 very quickly. Is there a hidden per-user or per-tenant rate limit that is being triggered here? Or is this a known issue with the BYOC Edge deployment in Singapore? I need to understand if this is a hard limit we have to work around with exponential backoff in our scripts, or if there is a configuration issue on the tenant side causing premature throttling. Any insights on how others handle bulk user updates without hitting these walls would be appreciated. I am currently trying to adjust the concurrency settings in JMeter to see if spreading the requests out over a longer duration helps, but I suspect the API side is the bottleneck.