Hi Stuart,
I tested something very similar recently and I believe the confusion comes mainly from the API Explorer schema rendering, not from the actual API contract itself.
The examples shared by Eystein align with what worked for us as well: customFields behaves as a flat key/value dictionary, not as nested objects.
So this structure is valid:
{
"name": "Soknad",
"priority": 300,
"workbinId": "a54de182-7e57-4eb1-a71c-3df2a3de86be",
"typeId": "bb857580-2f8f-491f-8d1b-72f103ff57c9",
"customFields": {
"cso_so_name_text": "Eystein",
"cso_duedate_date": "2025-09-29",
"cso_url_lookup_url": "https://www.vg.no"
}
}
What seems misleading is that the API Explorer auto-generates a generic object schema like:
"custom_key": {
"some_key": "some_value"
}
but the backend itself expects:
<string, primitive>
instead of:
<string, object>
I also strongly recommend using Pro Mode in API Explorer or testing through Postman/SDK because the standard Explorer UI sometimes injects incorrect example payloads for dynamic objects/maps.
One important production detail:
the custom field internal name and datatype must match exactly what was configured in Task Management.
For example:
*_text → string
*_integer → numeric
*_date → ISO date
*_url → URL/string
If the type mismatches, behavior can become inconsistent depending on the endpoint:
validation errors
silent field drops
partial updates
Another thing we noticed:
PATCH operations usually behave more predictably than bulk operations when testing new custom fields, especially while validating mappings and field names.
So overall, I would classify this more as an API Explorer/example inconsistency rather than an actual limitation in Workitem custom attributes support.
------------------------------
Gabriel Garcia
NA
------------------------------