Ran into a weird issue today with the Outbound Dialer API when attempting to scale up concurrent campaign initiations. We are simulating a high-volume BPO environment where multiple supervisors trigger campaigns simultaneously. The goal is to test if the api/v2/outbound/campaigns/{campaignId}/status endpoint can handle the burst of PUT requests to change status to RUNNING.
Here is the setup:
- Environment: Genesys Cloud US1
- Tool: JMeter 5.6.2
- Load Pattern: 50 threads, 0s ramp-up (instant burst), hitting the campaign status endpoint.
- SDK: Not using SDK, direct REST calls via JMeter HTTP Sampler.
The first 10-15 requests usually succeed with a 204 No Content response. However, as soon as the thread count exceeds roughly 20 concurrent requests within the same second, the API starts returning 503 Service Unavailable. The response body is empty, and no Retry-After header is present. This happens even though the total number of campaigns is low (only 5 campaigns being toggled).
We have verified that the service account has full outbound:campaign:manage permissions. Rate limiting seems unlikely because we are well below the documented 1000 req/min limit for this endpoint. Is there a hidden concurrency limit on the campaign status change action specifically? Or is this a known issue with the load balancer dropping WebSocket-like state changes under burst conditions?
We tried adding a random delay between 100ms and 500ms in JMeter, which stabilizes the test, but we need to know the hard limit for production planning. Does anyone have data on the actual throughput capacity of the outbound campaign status API under load?