“429 Too Many Requests” on POST /v2/outbound/campaigns when triggering a campaign via our AppFoundry integration. We are using standard OAuth scopes and hitting the limit immediately.
Note: Outbound API endpoints are subject to standard Platform API rate limits.
Is there a specific burst allowance for campaign activation that we are missing, or is this a hard block on tenant-level concurrency?
Make sure you implement exponential backoff in your AppFoundry script. The outbound API enforces strict tenant-level concurrency, not just burst allowances. Ignoring the Retry-After header will lock your integration out for longer periods. Check the X-RateLimit-Remaining response header to gauge safe request intervals before triggering campaign updates.
You need to strictly enforce the Retry-After header value from the 429 response in your AppFoundry logic, as ignoring it will cause immediate request rejection and potential IP-level throttling by the Genesys Cloud edge. The Outbound Campaign API does not have a special burst allowance for activation; it falls under the standard Platform API rate limits which are calculated per tenant and per endpoint. If your integration fires multiple campaign updates simultaneously without respecting the X-RateLimit-Remaining count, the system will block subsequent requests to protect database integrity. This is a common issue when scaling outbound operations, especially if the script does not pause between calls. Ensure your code parses the Retry-After integer (seconds) and waits that exact duration before the next attempt. Failing to implement this exponential backoff pattern will result in prolonged lockouts, disrupting your campaign scheduling workflow entirely.
For JMeter load testing scenarios, this behavior is even more pronounced. When simulating concurrent agents or high-volume API calls, you must configure the HTTP Request Sampler to handle 429 responses by adding a JSR223 PostProcessor that sleeps for the duration specified in the Retry-After header. Without this, your test plan will flood the endpoint, triggering a hard block that affects all users on the tenant, not just the test instance. The documentation suggests monitoring the X-RateLimit-Reset timestamp to align your request pacing with the window reset. This approach prevents unnecessary 429 errors and ensures that your integration or load test respects the platform’s capacity limits. It is critical to validate these headers in your development environment before pushing to production, as the rate limits are enforced strictly and consistently across all API versions.