POST /api/v2/wfm/schedules/shifts/{scheduleId}/publish returns HTTP 503 Service Unavailable after approximately 40 concurrent requests. The error response body contains: {"code":"service_unavailable","message":"The server is currently unable to handle the request due to a temporary overloading or maintenance of the server."}
I am running a load test using JMeter 5.6.2 to evaluate the throughput of the WFM schedule publishing endpoint. The goal is to simulate a peak scenario where multiple admin users publish shift templates simultaneously. The test plan uses a Thread Group with 50 virtual users, a ramp-up period of 10 seconds, and a loop count of 1. Each user executes a single HTTP Request sampler against the /api/v2/wfm/schedules/shifts/{id}/publish endpoint with the Content-Type: application/json header and a valid JWT token in the Authorization header. The payload includes a standard shift template with 10 agents assigned for a 4-hour block.
The environment is Genesys Cloud US-East. The initial requests (first ~35) complete successfully with HTTP 200 and a response time of under 2 seconds. However, as the concurrency increases, the response times spike to over 10 seconds, followed immediately by the 503 errors. I have verified that the API tokens are valid and have the necessary wfm:schedule:publish permission. I also checked the Genesys Cloud status dashboard, and all systems are reported as operational. There are no rate limit headers (429) in the successful responses, suggesting this is not a standard API rate limiting issue but rather a backend service capacity problem. Is there a known concurrent request limit for the schedule publish API? Should I be implementing a client-side retry mechanism with exponential backoff, or is this indicative of a need for increased capacity on the Genesys Cloud side? Any insights on how to tune the JMeter test to better reflect realistic burst patterns without hitting this hard limit would be appreciated.