- Just noticed that the Scripting API endpoints are dropping requests under load in the US1 environment.
- Running JMeter with 150 concurrent threads hitting /api/v2/architect/scripts.
- Getting 429 Too Many Requests errors after roughly 5 seconds of test execution.
- The error message indicates rate limit exceeded, but the documentation is vague on specific limits for this endpoint.
- Using standard OAuth2 client credentials flow for authentication.
- The issue persists even when reducing payload size to minimal JSON.
- Current JMeter config uses HTTP Request Defaults with keep-alive enabled.
- Looking for clarification on the exact rate limit thresholds for script creation and update operations.
- Need to understand if this is a global limit or scoped per tenant.
- Any insights on how to tune JMeter to stay within bounds without reducing concurrent thread count?
- Also checking if WebSocket connections impact these REST API limits.
- Will share full JMeter plan if needed for review.
You need to adjust the JMeter thread group to stagger the request initiation rather than firing all 150 threads simultaneously. The platform enforces strict rate limits on architect endpoints, and hitting them with a flat burst of traffic triggers immediate 429 responses. Configure the “Ramp-Up Period” in your thread group to spread the load over at least 60 seconds. This simulates a more realistic agent login pattern and prevents the API gateway from rejecting the entire batch due to sudden spikes in concurrent connections.
Implement a simple BeanShell pre-processor or use the built-in “Constant Throughput Timer” to enforce a delay between iterations. Setting a throughput of roughly 2-3 requests per second per thread group helps stay within the safe zone. Monitor the response headers for X-RateLimit-Remaining to fine-tune this value. If you continue seeing drops, check if your OAuth2 token refresh is also being throttled, as expired tokens under load can compound the error rate significantly.