We are encountering a persistent validation error when attempting to provision outbound contact lists via the Genesys Cloud Admin API. The goal is to automate this creation step within our Terraform workflow using a local-exec provisioner that calls curl. The endpoint is POST /api/v2/outbound/contactlists. The HTTP status code returned is 400 Bad Request. The error body indicates an INVALID_VALUE type.
The JSON payload appears to conform to the schema definition found in the developer documentation. We have verified that the contact list name is unique within the organization. The endpoint URL is valid and we have an active OAuth token with the required permissions. The issue seems isolated to the payload structure or a hidden validation rule.
Here is the curl command being executed by the provisioner:
curl -X POST "https://api.mypurecloud.com/api/v2/outbound/contactlists" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"name": "Automated_Test_List_001",
"type": "manual",
"contactSource": "api",
"columns": [
{
"name": "phone_number",
"type": "phone"
},
{
"name": "customer_id",
"type": "string"
}
]
}'
The response body is as follows:
{
"code": "invalidValue",
"message": "The value for column 'phone_number' is not valid.",
"status": 400
}
This message is confusing. We are not posting any actual contact data in this request. We are only defining the schema for the list. The documentation states that contact data is uploaded separately via a different endpoint. The column definition specifies the type as phone. This should be sufficient for list creation. We have tried changing the type to string. The error persists. We have tried removing the columns array entirely. The API returns a 500 Internal Server Error in that case. This suggests the columns array is required but the validation logic is flawed.
Has anyone else encountered this specific error when creating outbound contact lists via the API? We are using the latest version of the CX as Code provider. The state file is clean. There are no existing lists with this name. We are based in Europe/Berlin. The timezone settings in the environment are UTC. We suspect there might be a hidden requirement for the column definition that is not documented. Perhaps a mapping to a specific field is required. We have exhausted the obvious fixes. The curl command works for other resources. The token is valid. The network connectivity is fine. We are stuck on this validation error. It blocks our entire provisioning pipeline. We need a workaround or a fix. The error message references a value that does not exist in the payload. This is a bug in the API validation logic. We have raised a ticket with support. They have not responded yet. We need a solution now. The deadline is tomorrow. We are considering switching to the Python SDK. The SDK might handle this differently. We have not tested that path yet. The curl command is simpler. It is easier to debug. We prefer to keep it simple. We have checked the API version. It is v2. There is no v3 for this endpoint. We have checked the sandbox environment. The same error occurs. It is not an org-specific issue. It is a platform-wide behavior. We are confused by the error message. It claims the value is invalid. There is no value. There is only a type. The type is phone. Phone is a valid type. We have tried using the exact example from the documentation. The example does not work. The documentation is outdated. We need to know what the API actually expects. We have tried adding a default value. The API does not accept a default value in the column definition. We have tried adding a description. The API ignores the description. The error remains the same. We are running out of ideas. We have spent three hours on this. It should have taken ten minutes. The error message is not helpful. It does not point to the line in the JSON. It just says invalidValue. We have validated the JSON with a linter. It is valid JSON. The structure is correct. The types are correct. The names are correct. We are missing something. Something small. Something stupid. We have checked for typos. There are no typos. We have checked for hidden characters. There are no hidden characters. We have checked the encoding. It is UTF-8. We have checked the content type. It is application/json. We have checked the authorization. It is Bearer token. We have checked the endpoint. It is correct. We have checked the method. It is POST. We have checked the payload. It is correct. We are stuck. Please help.