Agent Scripting API 400 Bad Request during high-concurrency JMeter load test

General Discussion
1
  • Anyone know why the Genesys Cloud Agent Scripting API is returning a 400 Bad Request error when we push concurrent POST requests to /api/v2/conversations/agent-scripts via JMeter? We are running a load test to validate script assignment performance under high agent login volumes.
  • The environment is a Genesys Cloud BYOC instance with custom Architect flows triggering script assignments. We are using the standard OAuth2 client credentials flow for authentication, and the token is valid and refreshed correctly.
  • The JMeter test plan uses a Thread Group with 100 threads, ramp-up time of 10 seconds, and a loop count of 50. This results in approximately 500 concurrent requests per second hitting the scripting endpoint.
  • The error response body contains: {"code":"bad.request","message":"Invalid request payload","errors":[{"code":"invalid.field","field":"scriptId","message":"Script ID format is invalid"}]}. This is confusing because the scriptId in the payload is hardcoded and verified to be a valid UUID from the Genesys Cloud administration console.
  • We have tested the same payload with a single-threaded JMeter test, and it works perfectly without any errors. The issue only appears when concurrency exceeds 50 requests per second.
  • We are using the latest Genesys Cloud API documentation version (as of October 2023) and have confirmed that the Content-Type header is set to application/json.
  • The payload structure is:
{
"scriptId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"userId": "user-id-123",
"conversationId": "conv-id-456"
}
  • We suspect that the API might be rate-limiting or experiencing internal validation failures under load, but the error message suggests a payload issue rather than a rate limit (which would typically return a 429).
  • We have checked the Genesys Cloud platform status page, and there are no reported outages or maintenance windows for the Agent Scripting service.
  • Our JMeter config includes a CSV Data Set Config for dynamic user IDs and conversation IDs, but the scriptId remains constant across all requests.
  • We are based in Asia/Singapore and testing against the us-east-1 region, which might introduce latency, but we do not think this would cause a 400 error.
  • Any insights into why the API would reject valid payloads under high concurrency would be greatly appreciated. We need to understand if this is a known limitation or a configuration issue on our end.