Just noticed that our custom predictive routing integration is hitting aggressive rate limits on the /api/v2/predictiverouting/outbound/campaigns/{campaignId} endpoint when attempting to reconcile agent states in real-time. The integration handles roughly 500 concurrent sessions across two orgs, and we are seeing consistent 429 errors during peak morning hours (PST).
The standard retry logic with exponential backoff is not sufficient because the campaign status updates are time-sensitive. We need the state to reflect within a 2-second window to prevent duplicate calls. The error response does not include the typical Retry-After header, making it difficult to tune the polling frequency dynamically.
{
"message": "Rate limit exceeded",
"status": 429,
"status_code": 429
}
Is there a documented burst allowance for predictive routing endpoints that differs from the general API limits? We are using the Genesys Cloud SDK v6.7.0. Looking for insights on whether we should switch to a webhook-based approach for state changes or if there is a specific header we can leverage to prioritize these requests. The current architecture relies heavily on polling, which seems fragile under this load.