Is there a clean way to map Zendesk Ticket Custom Fields to Genesys Cloud Contact Attributes via Outbound API? In Zendesk, we just pushed metadata to the ticket object, but here the PUT /api/v2/outbound/contacts/{contactId} call returns a 400 Bad Request with invalid_attribute_type when trying to sync a string field.
{
"attributes": [
{
"key": "zendesk_priority",
"value": "High",
"type": "STRING"
}
]
}
The root of the issue is likely a mismatch between the attribute type definition in your Outbound Campaign configuration and the payload structure sent via the API. Genesys Cloud is strict about schema validation for contact attributes, especially when syncing from external sources like Zendesk. If the attribute was defined as NUMBER or BOOLEAN in the campaign settings, sending a STRING type value will trigger that 400 error.
First, verify the attribute schema in the Outbound Campaign. Go to Admin > Outbound > Campaigns > [Your Campaign] > Attributes. Ensure that zendesk_priority is explicitly defined as a STRING type. If it is missing, you must add it there before attempting the API call.
Second, check your API payload. The PUT /api/v2/outbound/contacts/{contactId} endpoint expects the attributes array to match the campaign definition exactly. Here is the correct JSON structure for a string attribute:
{
"attributes": [
{
"key": "zendesk_priority",
"value": "High",
"type": "STRING"
}
]
}
If the type is already correct, the issue might be related to API rate limiting or connection timeouts, especially if you are running this in a loop. For load testing purposes, ensure you are respecting the Genesys Cloud API limits. A good practice is to add a small delay between requests to avoid hitting the 429 Too Many Requests threshold.
| Requirement |
Value |
| API Endpoint |
PUT /api/v2/outbound/contacts/{contactId} |
| Attribute Type |
Must match Campaign Definition |
| Rate Limit |
~100 requests/second per org |
| Payload Format |
JSON with key, value, type |
Try redefining the attribute in the campaign UI as a String, then retry the API call. If it still fails, check the Genesys Cloud logs for more specific error details.
You need to align the attribute type in the campaign definition with the payload.
Cause: Genesys Cloud enforces strict schema validation for contact attributes.
Solution: Ensure the zendesk_priority attribute is explicitly defined as STRING in the outbound campaign configuration before sending the API request.
You might want to check at the outbound campaign attribute definitions.
- Ensure
zendesk_priority is explicitly defined as STRING in the campaign settings.
- Mismatched types between the campaign config and the API payload cause 400 errors.
The 400 error stems from the campaign attribute definition not matching the payload schema. The outbound campaign must have zendesk_priority defined as a STRING type before the API call succeeds.
Here is the Terraform configuration to enforce this schema during deployment:
resource "genesyscloud_outbound_campaign" "zendesk_sync" {
name = "Zendesk Priority Sync"
attributes {
key = "zendesk_priority"
type = "STRING"
is_user_defined = true
}
}
# Ensure the contact attribute matches
resource "genesyscloud_outbound_contact_list" "zendesk_contacts" {
name = "Zendesk Tickets"
attributes {
key = "zendesk_priority"
type = "STRING"
}
}
After applying this config, verify the attribute exists in the campaign via CLI:
genesys cloud outbound campaign get --id <CAMPAIGN_ID> | jq '.attributes[] | select(.key=="zendesk_priority")'
If the type is still incorrect, delete and recreate the attribute in the campaign. The API validates against the campaign definition, not the contact list definition.
Also check the Zendesk integration data action. If using a data action to push attributes, ensure the JSON schema in the data action definition matches the campaign attribute types. Mismatches here cause silent failures or 400s.
{
"schema": {
"zendesk_priority": {
"type": "string"
}
}
}
This setup worked for our Zendesk-to-GC sync pipeline. The key is strict type alignment across campaign, contact list, and data action definitions. Avoid dynamic types. Use static definitions in Terraform to prevent drift.
If the issue persists, check the campaign’s contactAttributes block in the API response. Ensure zendesk_priority is listed with type: "STRING". If it’s missing, the campaign hasn’t synced the attribute definition yet. Wait for the campaign to deploy fully before testing the API call.