Problem

• When making an API call using a 'value' for a custom field, that value is handled with case-sensitive matching
  • 'abc123' != 'ABC123'
• In Jira, custom field single- and multi-select values are handled with case-insensitive matching.
  • 'abc123' = 'ABC123'

Thus, an API call using 

"customfield_10101":{"value":"abc123"}

 will fail (400 error) and unhelpfully return 

{"errorMessages":[],"errors":{"customfield_10101":"Option id 'null' is not valid"}}%

(unhelpful because value is being used here, not id, and the problem is the value match/case sensitivity, not the lack of id)

 Suggested Solution

The desired behavior would be for API calls to handle case the same way Jira does; case-insensitively match ABC123 to abc123.

Why This Is Important

• While the solution is to simply write API calls to use the exact desired value, the current behavior is still inconsistent, and this inconsistency prevents certain workarounds (see below Workaround section)
• Users coming from other platforms expect this case-insensitive behavior

Workaround

The main reason this is important is because there isn't really a workaround. 

If you want to add abc123 & ABC123 both as options in the select list, which would be a workaround for the API call sensitivity in some cases, you will be prevented from 'creating a duplicate.' 

The only solution is to be aware of the inconsistent case-sensitivity and to use exactly the matching value.