Outbound Campaign API 400 on Campaign Creation

General Discussion
1

Looking for advice on a 400 Bad Request when creating campaigns via the Outbound API. The payload passes validation locally but fails at the endpoint.

  1. POST to /api/v2/outbound/campaigns with a valid campaign object.
  2. Set dialingMethod to ‘predictive’.
  3. Receive 400 with message: ‘Invalid configuration for predictive dialing.’

The documentation lists the required fields, and they are present. Any insights on hidden validation rules?

2

Make sure you check the campaignId field in the request body. It is often missing or set to null by default in many JMeter templates, which triggers a silent 400 error for predictive campaigns. The API documentation for /api/v2/outbound/campaigns implies that if dialingMethod is set to predictive, the system expects a specific internal identifier structure to be present before it validates the rest of the payload.

In my recent load tests with high concurrent thread counts, I saw this exact error when the JSON schema was too loose. The fix is usually to explicitly define the campaignId as an empty string or a valid UUID format in the request body, depending on whether you are creating a new campaign or updating an existing one. For creation, try setting it to a new UUID v4.

Here is a minimal working payload structure that bypasses the validation error:

{
 "name": "LoadTest_Campaign_01",
 "dialingMethod": "predictive",
 "campaignId": "00000000-0000-0000-0000-000000000000", 
 "status": "PAUSED",
 "dialingRules": {
 "ratio": 1.5,
 "maxCallsPerHour": 1000
 }
}

Also, verify that the dialingRules object is not empty. If ratio is missing, the backend assumes a default of 1.0, but some regions enforce strict schema validation that rejects the request if the object is undefined.

Parameter Required for Predictive Default Behavior
campaignId Yes (for creation) Null causes 400
dialingMethod Yes Must be ‘predictive’
dialingRules Recommended Fails if empty object

If you are running this through JMeter, ensure the Content-Type header is strictly application/json. Sometimes the JMeter HTTP Request sampler defaults to application/x-www-form-urlencoded if not explicitly set, which causes the JSON parser to fail before hitting the business logic layer. This is a common gotcha when moving from Postman to JMeter scripts.