My configuration keeps failing when pushing concurrent requests to the scripting endpoint. The setup involves JMeter threads hitting /api/v2/outbound/scripts in ap-southeast-1.
Running 50 concurrent users triggers immediate 429 Too Many Requests errors. The script works fine at low volume but fails under load.
JMeter version 5.6.2 with standard HTTP sampler. No custom headers except auth token. Region is strictly ap-southeast-1.
Need to know if this endpoint has a hard per-minute limit or if I need to implement backoff logic in the test script.
If I recall correctly, the scripting endpoint enforces strict rate limits that are often lower than what general API endpoints support, especially in ap-southeast-1. The 429 errors are likely triggered by hitting the burst limit before the steady-state rate kicks in. You need to implement a proper retry strategy with exponential backoff to handle these transient limits gracefully. Instead of hammering the endpoint, configure your JMeter test to respect the Retry-After header if present, or use a fixed delay with a random jitter to avoid thundering herd problems. This approach mimics how our WFM integration handles schedule publishing spikes, where we throttle requests to stay within the allowed throughput without triggering circuit breakers.
Here is a sample configuration for the HTTP Request Defaults in JMeter to handle this. Set the “Number of Retries” to 3 and “Retry Interval” to 1000 ms. Additionally, add a “Constant Throughput Timer” to control the request rate per minute. For 50 concurrent users, aim for a throughput that stays well below the documented limit, typically around 60-100 requests per minute for this specific endpoint. If you are still seeing 429s, check if your token is being refreshed too frequently, which can add unnecessary overhead. Focus on stabilizing the request rate before increasing concurrency. This method usually resolves the issue by aligning the test load with the actual API capacity, preventing the immediate rejection of requests.
It depends, but generally… the scripting api in ap-southeast-1 is definitely stricter than what we are used to seeing in us-east-1 or eu-west-1. coming from a zendesk background, i remember how their ticket creation endpoints would just throttle you silently if you pushed too hard, but genesys gives you that nice 429 header to work with.
the suggestion about exponential backoff is spot on. however, for jmeter specifically, the standard http sampler doesn’t automatically parse the Retry-After header. you need to add a JSR223 PostProcessor to handle this logic properly. otherwise, your test just fails flat.
here is a quick groovy snippet to drop into your thread group. it checks the status code and pauses the thread if it hits a 429:
if (prev.getResponseCode() == "429") {
def retryAfter = prev.getResponseHeader("Retry-After")
if (retryAfter) {
def delay = Integer.parseInt(retryAfter) * 1000
Thread.sleep(delay)
log.info("Paused for ${delay}ms due to 429")
}
}
also, make sure you are not hitting the global tenant limit. in our migration projects, we often see teams underestimate how many script updates trigger rate limits. if you are doing bulk updates, consider batching them or using the bulk api endpoints if available, as they are usually more tolerant of higher payloads.
another thing to check is the oauth token scope. sometimes the 429 is actually a misconfigured scope causing a rapid rejection loop rather than a true rate limit. double-check that your token has outbound:read and outbound:write.
we are currently in a migration phase for a client in paris, and we hit similar walls in eu-west-1. the fix was always about respecting those headers. don’t fight the rate limiter, work with it. the api is designed to protect the platform, so your test setup needs to mimic real-world agent behavior, which includes pauses and retries. good luck with the load test!
I typically get around this by decoupling the load test from the immediate API response handling, treating the 429 as a transient state rather than a failure condition. The scripting endpoints in ap-southeast-1 have stricter burst limits than eu-west-1, so standard HTTP samplers often fail to respect the Retry-After header dynamically.
To stabilize the JMeter execution:
Add a JSON Extractor to capture the retry-after value from the 429 response headers.
Implement a BeanShell or JSR223 PostProcessor that calculates the sleep duration based on this value, adding a small random jitter (50-200ms) to prevent synchronized retries.
Configure the HTTP Request sampler to continue on error, allowing the script to loop and retry only after the calculated delay.
Monitor the Retry-After distribution to identify if the limit is per-tenant or per-endpoint.
This approach mimics the resilience patterns used in ServiceNow Data Actions when handling webhook payloads under high concurrency. It ensures the test reflects realistic integration behavior rather than raw throughput limits.