See my question here.

Case 1 - Arrays (copied)

Most of the standard custom fields that JIRA ships have meta data that says they are arrays with string values. That normally means you need to provide a JSON array of option ids. Cascade select is a odd case even though it reports the same schema but needs to be handled differently. It has historically been an odd case (wink).

The trouble is for an arbitrary custom field that reports meta data as "array" and with items of "string" there doesn't seem to be a way to know the format or content of the data that is expected to set the value of the field. Am I missing something here? One would assume meta data would give you enough information to determine that, but it doesn't. Providing an array of values results in an error. How does one create a representation of data for an arbitrary custom field that represents itself as accepting array values but does not? Also, what indication is there that it needs option ids instead of regular strings? This seems like an omission from the metadata available.

For instance, the agile custom fields look like arrays, but don't accept array values:

schema":

,

customfield_11261": "ZAGILE-1",

Case 2 - 3rd party custom fields

Here is a Tempo field with the following metadata:

"customfield_10600":{"required":true,"schema":{"type":"account","custom":"com.tempoplugin.tempo-accounts:accounts.customfield","customId":10600},"name":"Account","hasDefaultValue":false,"operations":["set"]},

This happens to be a numeric field. However, there is no indication of that in the metadata.
Worse, an update using a string value gives "not numeric" error even though the string value is actually a numeric value. There doesn't appear to be a generic way to determine that a numeric is required. The only obvious way is magically knowing about this specific custom field requires a numeric entry.