Predictive Routing dialer returning 400 on campaign activation

Anyone know why the predictive routing dialer is rejecting our campaign activation requests? The /api/v2/outbound/dialers/predictive endpoint is consistently returning a 400 Bad Request when we attempt to enable a new predictive strategy.

{"message":"Invalid configuration: Max concurrent calls exceeds account limit","errors":["max_concurrent_calls"]}

We have verified the account limits and they should support this volume, yet the API refuses to proceed.

If I remember right, the 400 error on predictive campaign activation often stems from a mismatch between the configured max_concurrent_calls and the actual available capacity in the account. Even if the account limit appears high, the Platform API enforces strict checks against reserved capacity for other active dialers or real-time call loads. This is especially common when running load tests or simulations from regions like Asia/Singapore, where latency might cause race conditions in capacity validation.

You should verify the current capacity reservation by querying the /api/v2/outbound/capacity endpoint. The response will show available_concurrent_calls versus reserved_concurrent_calls. If the sum of your new campaign’s max_concurrent_calls and existing reservations exceeds the total_concurrent_calls limit, the API will reject the activation. Here is a quick curl example to check your current state:

curl -X GET \
 'https://api.mypurecloud.com/api/v2/outbound/capacity' \
 -H 'Authorization: Bearer <your_token>'

Look specifically at the outbound object within the JSON response. If the numbers don’t add up, you may need to reduce the max_concurrent_calls in your campaign payload or wait for other dialers to finish their bursts. In my JMeter tests, I’ve seen this happen when multiple predictive campaigns try to scale up simultaneously without staggered start times.

A common fix is to implement a retry mechanism with exponential backoff in your automation script. If the 400 persists, check for any pending webhook callbacks from the dialer service that might be holding capacity reservations open. Sometimes, silent failures in previous campaign stops leave phantom reservations active until the timeout expires. Monitoring the WebSocket connection limits can also help identify if the client-side constraints are contributing to the issue, though the 400 usually points directly to the account-level capacity cap.