400 INVALID_VALUE on POST /api/v2/analytics/outbound/contactlists

NICE CXone API & Integrations
1

No idea why this is happening, the Genesys Cloud API rejects this payload with a 400 INVALID_VALUE error. The JSON structure matches the schema definition exactly, including the required name and contactListType fields, yet the server refuses to process the request.

{
 "name": "k6_load_test_list_24",
 "contactListType": "CSV",
 "delimiter": ",",
 "encoding": "UTF-8"
}

Running this via k6 with valid OAuth2 Bearer tokens. Any idea which field is triggering the validation failure?

2

If I recall correctly, the issue is rarely the static fields like name or contactListType. The 400 INVALID_VALUE error on outbound contact lists usually stems from the columns array or missing metadata required for CSV parsing.

The API expects explicit column definitions when creating a CSV list, even if you plan to upload data later. Without this, the schema validation fails silently on the server side.

  1. Define the columns array. This is mandatory for CSV types to establish the schema.
  2. Verify OAuth scopes. Ensure your token includes analytics:outbound:write.
  3. Check the delimiter field. While , is standard, ensure it matches your actual data.

Here is the corrected JSON payload using the PureCloudPlatformClientV2 SDK structure (translated to raw JSON):

{
 "name": "k6_load_test_list_24",
 "contactListType": "CSV",
 "delimiter": ",",
 "encoding": "UTF-8",
 "columns": [
 {
 "name": "id",
 "type": "String",
 "required": true
 },
 {
 "name": "phone_number",
 "type": "String",
 "required": true
 }
 ]
}

You can also validate this via curl to isolate SDK issues:

curl -X POST "https://api.mypurecloud.com/api/v2/analytics/outbound/contactlists" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
 -H "Content-Type: application/json" \
 -d '{
 "name": "k6_load_test_list_24",
 "contactListType": "CSV",
 "delimiter": ",",
 "encoding": "UTF-8",
 "columns": [
 { "name": "id", "type": "String" },
 { "name": "phone_number", "type": "String" }
 ]
}'

Always inspect the Audit API logs (/api/v2/auditlogs) if the error persists. It often reveals hidden validation rules not documented in the main schema. This approach resolved similar issues in my automation pipelines.