For option2 fields (e.g., Tempo Account), should the API value always be a direct integer id?

[Kumkum Geervani]

Hi Team,

I recently ran into an issue while creating Jira issues via API when trying to set the Tempo Timesheets Account custom field.

When I tried passing it like a regular single-select field:

"io.tempo.jira__account": { "value": "Billable" }

I got the following error:

{"io.tempo.jira__account":"Can not deserialize instance of java.lang.Long out of START_OBJECT token\n at [Source: N/A; line: -1, column: -1]"}

After researching, I found that the correct way to set this field is by passing the id directly, for example:

"io.tempo.jira__account": 1
        or
"customfield_100xx": 1

This works, but it’s different from how other custom fields with single select options behave. For normal single-select fields, I can pass an object like this:

"customfield_100yy": { "value": "Billable" }

Here’s what the field schema looks like from the API:

{
"type": "option2",
"custom": "com.atlassian.plugins.atlassian-connect-plugin:io.tempo.jira__account",
"customId": 100xx,
"name": "Account",
"key": "io.tempo.jira__account",
"hasDefaultValue": false,
"operations": ["set"],
"allowedValues": [
{ "id": 1, "value": "Billable" },
{ "id": 2, "value": "Non-Billable" }
],
"fieldId": "customfield_100xx"
}

My question:

• Does the option2 type in Tempo’s Account custom field schema always expects an id (integer) instead of a { "value": "..." } or {"id": ..} object?

• Or is this behavior specific to Tempo custom fields and not a general rule for Jira custom fields of type option2?

• Based on what conditions can I differentiate between Tempo Account custom field and other custom fields(created directly in jira)??

I’d like to understand the rule here so we can handle these cases consistently in our integration.

Thanks in advance for clarifying!