Hi Harshali,
The confusing part here is that the API Explorer examples can be misleading depending on the mode being used.
For customFields, the API expects a flat key/value structure where each key is the API name of the custom attribute configured in Task Management.
Example:
{
"name": "sample",
"typeId": "7f11b5da-f1ba-4639-92fd-1fef825752da",
"customFields": {
"claim_id_text": "12345",
"claim_status_text": "Open"
}
}
So the first key is not arbitrary.
It must be the actual custom field API name.
The nested object structure shown sometimes in API Explorer:
"customFields": {
"someKey": {
"anotherKey": "value"
}
}
does not appear to be the expected runtime payload for standard custom field usage.
What worked for us was using Pro Mode and sending the raw JSON directly with the custom field names mapped flat inside customFields.
Also make sure the field names match exactly the configured custom attribute IDs/types in Task Management (_text, _integer, _date, etc.), otherwise the API may silently reject or ignore the values.
------------------------------
Gabriel Garcia
NA
------------------------------
Original Message:
Sent: 05-25-2026 07:44
From: Harshali Bhure
Subject: Work item creation API
Hi All,
For this API,
post
/api/v2/taskmanagement/workitems
Create a workitem
there seems to be a structure change for custom attributes parameter of this API. It is itself coming in the form of object- post which we can add name value pair for each attribute. I am having difficulty in understanding what is to be added as first key in custom attributes- we cannot keep it blank. Below is my simple body of API, but what should be custom attributes key at the start? Could anyone help plz.
{
"name": "sample",
"typeId": "7f11b5da-f1ba-4639-92fd-1fef825752da",
"customFields": {
"whatshouldthisBe": {
"Claim ID": "12345",
"ClaimStatus": "Open"
}
}
}
#API/Integrations
------------------------------
Harshali Bhure
Associate Manager
------------------------------