Data Action 429s during JMeter spike in ap-southeast-1

Can anyone clarify the exact rate limiting behavior for custom Data Actions when called via the Architect API under high concurrency? We are running a load test from ap-southeast-1 using JMeter 5.6.2 to simulate a sudden influx of concurrent calls. The goal is to test system resilience when hitting 200 concurrent executions per second.

The issue arises when the throughput exceeds roughly 50 calls per second. The API starts returning 429 Too Many Requests with a Retry-After header, but the values seem inconsistent. Sometimes it suggests waiting 1 second, other times 5 seconds. This causes our JMeter threads to queue up and eventually time out, skewing our latency metrics.

We are using the standard REST endpoint /api/v2/architect/data/actions/{actionId}/executions. The payload is minimal, just a few string fields. Is there a specific header or configuration we can adjust to handle these spikes better? Or is the limit strictly fixed per organization? We need to understand if this is a hard cap or if we can negotiate higher limits for our load testing scenario.

It depends, but generally…

“rate_limit_exceeded”: “data_action_execution”

In Zendesk, custom triggers were far less restrictive, so this 50 TPS ceiling often catches migrants off guard. Try adding a retry_after header parser to your JMeter script to handle the backoff automatically.