Can anyone explain why the /api/v2/conversations/calls/{conversationId}/scripts endpoint returns a 400 Bad Request when simulating high concurrency from Asia/Singapore?
Running a load test with JMeter 5.6.2. Ramping up to 50 concurrent threads. Each thread attempts to assign a script to a mock conversation immediately after creation. Single requests work fine in Postman. Under load, ~60% of requests fail.
Error response body:
{
"message": "Invalid script assignment request",
"errors": [
{
"code": "SCRIPT_NOT_FOUND",
"message": "The specified script ID does not exist or is not accessible."
}
]
}
The script ID is valid. It exists in the tenant. Permissions seem correct. The issue only appears when threads exceed 20. Is there a hidden rate limit on script assignment actions? Or is the conversation state not fully propagated before the script assignment hits the API?
Payload being sent:
{
"scriptId": "a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8",
"action": "ASSIGN"
}
Environment: Genesys Cloud Platform, APAC Region. Any insights on handling this latency or queueing issue would be appreciated. Stuck on this for two days.
What’s probably happening here is that not the endpoint itself, but the rate limiting and state synchronization between conversation creation and script assignment in the APAC region. When ramping to 50 concurrent threads, you are probably hitting the API gateway’s burst limit before the conversation resource is fully indexed for script attachment. In WFM, we see similar latency spikes when pushing schedule updates during peak handover times; the system needs a beat to settle.
To fix this, implement a retry mechanism with exponential backoff in your JMeter script. Do not fire the script assignment immediately after the 201 Created response. Add a small delay or a polling check for conversation readiness. Also, ensure your JMeter thread group is configured to handle asynchronous responses correctly.
Here is a sample JMeter BeanShell PreProcessor to add a dynamic delay based on response status:
import java.util.concurrent.ThreadLocalRandom;
// Add a random delay between 500ms and 2000ms to stagger requests
int delay = ThreadLocalRandom.current().nextInt(500, 2001);
Thread.sleep(delay);
// Check if previous sampler failed due to rate limiting (429 or 400)
String prevStatus = prev.getResponseCode();
if ("400".equals(prevStatus) || "429".equals(prevStatus)) {
// Increase delay significantly for next attempt
Thread.sleep(3000);
log.info("Rate limit hit, backing off...");
}
Additionally, verify that your mock conversations are being created in the same region as the script endpoint. Cross-region calls add latency that exacerbates timeout issues under load. We usually see a 15-20% drop in 400 errors just by aligning the data residency and adding this staggered load pattern. Check your JMeter listeners for the exact timestamp of the 400s; they often cluster right at the ramp-up peak.