Screen recording api 429 on jmeter load

General Discussion
1

getting 429 too many requests on /api/v2/recording when hitting 50 concurrent calls. using sdk 1.2.0 and jmeter 5.4. rate limit is not resetting even after 60s. is this a hard limit for screen recording endpoints?

2

This is typically caused by the default rate limiting policy applied to the /api/v2/recording endpoint, which enforces a strict request quota per tenant ID. The 429 status indicates that the concurrent session creation requests have exceeded the allowed threshold, regardless of the 60-second wait. The limit does not reset based on time alone if the queue backlog persists.

To resolve this, implement exponential backoff in the JMeter script. Do not retry immediately. Instead, parse the Retry-After header from the 429 response. This header specifies the exact seconds to wait before the next request. Additionally, consider batching screen recording session starts if the business logic allows. For legal discovery workflows, ensuring the chain of custody is maintained during retries is critical. Verify that the SDK is not inadvertently hammering the endpoint due to a missing error handler. Check the response payload for the specific quota reset timestamp.

3

Make sure you decouple your load testing strategy from the synchronous recording creation flow. The 429 errors you are seeing are not necessarily a hard cap on the endpoint itself, but rather a symptom of how the rate limiter calculates burst capacity when concurrent requests spike. In a multi-tenant AppFoundry environment, we often see this behavior when the client does not respect the Retry-After header precisely or when the request payload includes redundant metadata that triggers additional validation checks.

To stabilize this under JMeter, try restructuring the test plan to handle rate limits more gracefully:

  1. Implement Dynamic Backoff: Do not use a static 60-second wait. Extract the Retry-After value from the 429 response header using a JSON Extractor or Regular Expression Extractor. Store this in a JMeter variable and use it in a Timer or If Controller to delay the next request. This aligns with the server’s actual reset window.
  2. Reduce Payload Size: Ensure the initial request to /api/v2/recording only includes mandatory fields. Extra parameters can slow down the rate limiter’s internal queue processing.
  3. Use Asynchronous Polling: Instead of blocking threads waiting for the recording to finalize, initiate the recording and then poll the status endpoint separately with a lower concurrency level. This reduces the load on the primary creation endpoint.
  4. Verify OAuth Token Scope: Confirm that the multi-tenant OAuth token being used has the minimal required scopes. Over-scoped tokens can sometimes trigger stricter rate limit buckets in the platform API gateway.

This approach usually resolves the backlog issue by smoothing out the request rate rather than fighting the limiter with brute force. If the issue persists, check if you are hitting the global tenant limit rather than the endpoint-specific limit by reviewing the X-RateLimit-Remaining header in the response.