Outbound Campaign API 429s during JMeter load test

General Discussion
1

Looking for advice on handling rate limits for outbound dialing APIs.

  • Environment is Genesys Cloud US-East.
  • Using JMeter 5.6 for performance testing.
  • Goal is to simulate 100 concurrent users updating campaign settings.
  • Endpoint used is PUT /api/v2/outbound/campaigns/{campaignId}.
  • Error received is 429 Too Many Requests after 60 seconds.
  • Payload size is small, around 2KB JSON.
  • Rate limit headers show x-ratelimit-limit as 1000 and x-ratelimit-remaining as 0.
  • Tried adding random delay between 100ms and 500ms in JMeter timer.
  • Issue persists even with delay.
  • Not sure if this is a global API limit or specific to outbound module.
  • Documentation mentions burst limits but does not specify exact values for campaign updates.
  • Need to know best practice for throttling requests in load test scripts.
  • Any insights on retry logic or backoff strategies would be helpful.
  • Current setup uses basic auth token for service account.
  • Service account has Outbound:Admin role.
  • No changes made to architect flows during test.
  • Focusing only on campaign metadata updates.
2

const handleRateLimit = async (response, retryCount = 0) => {
if (response.status === 429) {
const retryAfter = parseInt(response.headers[‘retry-after’], 10);
await new Promise(resolve => setTimeout(resolve, retryAfter * 1000));
return makeRequest(retryCount + 1);
}
return response;
};

> Error received is 429 Too Many Requests after 60 seconds.

The 429 indicates the Genesys Cloud edge has enforced the rate limit for outbound campaign updates. The `x-ratelimit-limit` header suggests a cap of 1000 requests, but concurrent JMeter threads likely exceed the burst allowance.

Integrate a retry mechanism with exponential backoff. The `retry-after` header dictates the wait time. For ServiceNow integrations, this logic prevents Data Action failures during high-volume syncs. Ensure your JMeter script respects the `retry-after` value rather than hammering the endpoint.

Also, verify if the campaign updates are idempotent. If multiple threads update the same `campaignId` simultaneously, consider batching updates or using a queue to serialize requests. This approach aligns with best practices for digital channel webhooks, where payload validation and rate limiting are critical for stability.