GetResponse API Custom Fields
We're deep into automating our lead nurturing workflows and a critical piece involves programmatically updating specific custom fields for existing GetResponse contacts via their API. This synchronization is crucial for our CRM to accurately reflect and drive GetResponse segmentation for targeted campaigns.
However, we're hitting an unexpected roadblock: a consistent 400 Bad Request or 422 Unprocessable Entity when attempting these updates. The issue seems to stem from the payload structure for custom-fields data, especially when trying to update multiple fields or fields with specific data types. The GetResponse documentation on this particular API integration nuance feels a bit ambiguous for complex update scenarios.
We've been trying a PUT request to /contacts/{contactId} with a payload structured like this, but it's consistently failing:
PUT /v3/contacts/{contactId}
Authorization: api-key {your_api_key}
Content-Type: application/json
{
"customFields": [
{
"customFieldId": "abc123def456",
"value": ["new_value_for_field_1"]
},
{
"customFieldId": "ghi789jkl012",
"value": ["another_value"]
}
]
}And the typical error response we're seeing is similar to:
{
"message": "Invalid custom field value format",
"code": 1007
}Can anyone share the definitive correct JSON payload structure for updating multiple custom fields for a single contact via the GetResponse API? Are there specific requirements for different custom field types (e.g., text, number, dropdown) when sending the value array? Any common pitfalls for this type of API integration that we might be overlooking?
Thanks in advance for any help!
2 Answers
Amit Yadav
Answered 3 days agoThat 400 Bad Request or 422 Unprocessable Entity with custom fields is a classic and, frankly, quite annoying hurdle in API integration, especially when you're deep into refining your marketing automation flows. We've definitely run into this exact scenario with GetResponse before, and it often boils down to how the value is structured within the customFields array.
For most standard custom field types in GetResponse (text, number, single-select dropdowns), the API expects the value to be a direct string, not an array containing a string. While it might seem intuitive to send an array, especially when updating multiple fields, GetResponse's API typically processes each custom field's value as a singular string. Your example payload is failing because "value": ["new_value"] is interpreted as an invalid format for a field that expects a simple string like "new_value". Here's the definitive correct JSON payload structure you should use:
PUT /v3/contacts/{contactId}
Authorization: api-key {your_api_key}
Content-Type: application/json
{
"customFields": [
{
"customFieldId": "abc123def456",
"value": "new_value_for_field_1"
},
{
"customFieldId": "ghi789jkl012",
"value": "another_value"
},
{
"customFieldId": "xyz_number_field",
"value": "12345"
},
{
"customFieldId": "pqr_dropdown_field",
"value": "Option A"
}
]
}Notice how the value is a plain string for each custom field. For number fields, send the number as a string (e.g., "12345"). For dropdowns, ensure the string matches one of the predefined options exactly (case-sensitive). Common pitfalls beyond this payload structure include using an incorrect customFieldId (double-check these in your GetResponse account under 'Custom Fields'), or attempting to send values that violate the field's type or validation rules (e.g., non-numeric characters to a number field).
Mariana Rodriguez
Answered 3 days agoThat tip about the value being a direct string completely fixed the 400 Bad Request errors for most fields, but now we're seeing an "Invalid custom field value format" error specifically when trying to update multi-select dropdown fields; they still seem to expect an array.