Outbound Campaign API 400 Bad Request on 'dialingPolicy' field

POST to /api/v2/outbound/campaigns returning 400 Bad Request when dialingPolicy is set to PREDICTIVE without powerLevel explicitly defined in the payload. The documentation implies defaults should apply, but the schema validation rejects the request. Is this a known strictness issue in the v2 API, or is powerLevel mandatory for all predictive campaigns regardless of the strategy?

The 400 error on /api/v2/outbound/campaigns with dialingPolicy: PREDICTIVE is a strict schema validation, not a bug. While the UI might hide powerLevel when it defaults to 1.0, the API requires it explicitly if the strategy is predictive. This is a common tripwire during load testing setup scripts.

Here is the minimal valid JSON payload structure. Notice powerLevel is inside the dialingPolicy object, not at the root level.

{
 "name": "LoadTest_Campaign_Predictive",
 "campaignType": "CALL",
 "dialingPolicy": "PREDICTIVE",
 "powerLevel": 1.0,
 "wrapUpPolicy": "NONE",
 "status": "RUNNING",
 "contactLists": [
 {
 "id": "your-contact-list-id"
 }
 ],
 "skills": [
 {
 "id": "your-skill-id"
 }
 ],
 "routingRules": [
 {
 "expression": "true",
 "actions": [
 {
 "type": "QUEUE",
 "queueId": "your-queue-id"
 }
 ]
 }
 ]
}

If you omit powerLevel, the backend assumes an invalid state for predictive dialing because it cannot calculate the agent availability ratio. In JMeter, I usually parameterize powerLevel to test different concurrency thresholds. Setting it too high (e.g., > 5.0) without enough agents causes immediate call abandonment, which might look like a 408 or 502 in your logs, but the 400 is purely a payload schema issue.

Also, check that contactLists and skills are populated. The API sometimes returns a generic 400 if these are empty or null, masking the actual missing powerLevel error. Validate the JSON against the Swagger spec before firing requests. The v2 API is stricter than v1 here.