My current config is completely failing… Hitting 429 Too Many Requests on POST /api/v2/scripts when attempting to load test script creation workflows. Running JMeter 5.6.2 from Singapore to simulate high-volume script updates. Single thread passes fine. At 30 concurrent threads, responses degrade rapidly.
The goal is to validate platform stability under bursty script modification loads, similar to what might happen during peak shift changes or campaign updates. The test plan mimics a scenario where multiple supervisors or automated processes update agent scripts simultaneously.
Here is the JMeter thread group configuration:
thread_group:
threads: 30
ramp_up: 10
loop_count: 5
scheduler: true
duration: 300
http_request_defaults:
endpoint: /api/v2/scripts
method: POST
headers:
Authorization: Bearer ${access_token}
Content-Type: application/json
X-Genesys-Id: ${unique_script_id}
json_body:
name: "Load Test Script ${__threadNum}"
type: "agent"
steps:
- type: "say"
text: "Testing load"
The error response includes:
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 1
{
"message": "Rate limit exceeded",
"code": "too_many_requests"
}
I am aware of general API rate limits, but this feels like a specific throttle on the scripting endpoint. The documentation mentions global limits, but does not specify per-endpoint throttling for script operations. Is there a known limit on script creation/update requests per minute? Or is this a broader platform API constraint?
Also, the Retry-After header suggests backing off, but in a real-world scenario, we need to ensure scripts are updated in near-real-time. How should we handle this in our integration? Should we implement exponential backoff, or is there a way to request a higher limit for our tenant?
Any insights or workarounds would be appreciated. I am trying to avoid hitting these limits during our production rollout.