What is the correct way to handle 429 errors during high-concurrency analytics export?

What is the standard approach to batch export interaction data without hitting rate limits in a load test scenario?

We are setting up a new performance benchmark for our reporting pipeline. The goal is to pull historical interaction data for 50,000 calls within a 10-minute window. We are using the /api/v2/analytics/interactions/queries endpoint.

Currently, we are sending requests sequentially from a JMeter thread group. The initial requests return 202 Accepted with a jobId. However, after about 50 concurrent jobs, the API starts returning 429 Too Many Requests. The Retry-After header is not always present, which makes implementing a standard backoff strategy difficult.

Here is our current JMeter configuration:

  • Thread Group: 20 threads
  • Loop Count: 2500
  • Ramp-Up: 0 seconds (instant start)
  • Request Method: POST

The error response body looks like this:

{
 "message": "Too many requests",
 "status": 429
}

We suspect the issue is related to the global rate limit for the organization or the specific user token we are using. We are testing in the us-east-1 region. The documentation mentions rate limits but doesn’t specify exact thresholds for analytics queries.

Is there a recommended pattern for handling this? Should we be using webhooks to poll for job completion instead of actively checking the status endpoint? We tried switching to webhooks, but the callback latency seems high when the queue is full.

Any advice on structuring the request flow to avoid getting blocked would be appreciated. We need to ensure the export process is stable before we scale up to 100k interactions.