Anyone know why the migration script keeps failing with a 400 Bad Request when trying to replicate Zendesk ticket tags as Genesys Cloud custom data fields? We are moving from Zendesk Support to Genesys Cloud Voice and Digital, and the plan is to map our legacy ticket tags to GC custom attributes for reporting. The goal is to preserve the historical context of customer issues in the new interaction logs.
The error occurs on the /api/v2/customattributes endpoint. The payload attempts to create a string-type custom attribute that mirrors a specific Zendesk tag group. However, the API rejects the request with a validation error regarding the dataType field. In Zendesk, tags are simple strings, but Genesys Cloud seems to require a more explicit definition for custom data fields during bulk import.
Here is the JSON payload being sent:
{
"name": "zendesk_tag_priority",
"dataType": "string",
"description": "Migrated from Zendesk ticket tags",
"system": false,
"values": [
{
"name": "high",
"system": false
},
{
"name": "low",
"system": false
}
]
}
The response indicates INVALID_REQUEST_BODY with the message The field 'dataType' must be one of [ENUM, STRING, INTEGER, BOOLEAN, DATETIME]. Wait, string is in the list. But looking closer at the error trace, it seems the issue might be related to the values array. In Zendesk, tags are dynamic and open-ended. Genesys Cloud custom attributes with an ENUM data type require predefined values, but we are trying to set dataType to string while also providing a values array, which might be conflicting.
Is there a specific way to handle open-ended tags from Zendesk in Genesys Cloud? Should we drop the values array entirely and rely on free-text entry, or is there a migration tool that handles this mapping automatically? We are using the Genesys Cloud API v2 and the standard Python SDK. Any advice on how to structure this payload to avoid the 400 error would be greatly appreciated. We want to ensure the historical data integrity is maintained without manual entry.