The v3 POST/PATCH API to create/update an item is far more complicated than it needs to be… To build the JSON for the update… I need to known which fields are in which section. It needs a call to get meta-data of the workspace. I also need to know the field types, this takes another call. Field IDs are unique, so why do I have to tell the server which section a field is in? But my question here is… On the INTEGER, I can specify “5” as a string, and it is intelligent enough to accept this and cast to an Int. But only if the existing field is empty. Otherwise I get an error. --> Can the API please be changed to provide this flexibility when there is an existing value? It would generally save the second of the two calls above, and make it a bit more flexible? [I'm expecting feedback about validity of json here. But in the example below, “link” and “fields” must be in this order. If “fields” is first, still valid json, then I receive a success 204 but the data is not actually updated !? ] --> Can you please consider making an API that accepts a payload like this: PATCH /api/v3/999/items/12345?easyPayload=true&ignoreInvalidFields=true&ignoreMissingPicklist=true { “DESCRIPTION”: “xx”, “EXAMPLE_STR”: “xx”, “EXAMPLE_INT”: “5”, or 5 “EXAMPLE_DATE”: “2025-05-01”, “JUST_IGNORE_THIS_IF_FIELD_DOES_NOT_EXIST”: “whatever” “COUNTRY_PICKLIST”: “Something”, … quietly ignore if no such value “COUNTRIES_MULTI_PICKLIST”: ["UK", "USA", "France" ] } (Ideally URL fields rather than another ugly Content-Type header) This would greatly reduce the complexity of the client code needed to make a REST call. Please consider this for the next API!
Show More