I’m trying to build a Python script that automatically creates issue tickets in our Jira system. The problem I’m running into is with custom fields - I can’t seem to get the syntax right and keep hitting errors.
Our team has several custom fields set up, and one of them is customfield_15400 which should default to “NO”. But whenever I try to set this field in my Python code, I get this error message:
response text = {"errorMessages":[],"errors":{"customfield_15400":"Could not find valid 'id' or 'value' in the Parent Option object."}}
Here’s the code I’m using:
app_mapping = {'WebApp':'WA', 'Mobile':'MB'}
epic_mapping = {'WebApp':'WA-205', 'Mobile':'MB-4567'}
for idx, record in defects.iterrows():
ticket = jira_client.create_issue(project= app_mapping[record['Platform']], \
summary= "[Bug Report] Issue found in '%s' feature on '%s'" % (record['Action'], record['Page']), \
issuetype= {'name':'Bug'},\
customfield_15400="No"
)
I’ve tried looking through documentation but can’t figure out the proper way to handle custom fields. What am I doing wrong here?
you’re passing a string but jira wants an object. try customfield_15400={'value': 'NO'} instead of just "No". also double-check that your value matches exactly what’s in jira - these custom fields are super picky about case.
Had this exact problem building our deployment automation tools. It’s definitely the object structure, but there’s another gotcha nobody’s mentioned yet. Some custom fields use option IDs instead of display values, especially if they were migrated from older Jira versions. When you get that “Parent Option” error, it usually means the field has cascading options or was set up with specific ID mappings. Try the numeric ID first - something like customfield_15400={'id': '10001'}. You can find these IDs by doing a GET request on an existing ticket that has this field populated, then check the response structure. Older custom fields almost always need IDs rather than string values, even for simple dropdowns.
This happens because Jira’s API is picky about custom field formats. Select-type fields need specific data structures, not just strings. I hit this same issue last year when connecting our ticketing system. First, do a GET request to see how the field’s actually structured. Try customfield_15400={'value': 'NO'} - but double-check the capitalization matches your Jira setup exactly. Here’s what tripped me up: some custom fields need both an ID and value, especially the ones with parent-child relationships. Use Jira’s REST API browser to inspect the field config, or just ask your Jira admin what structure this field actually wants.
That error usually means Jira wants an object structure for the custom field, not just a string. Since customfield_15400 looks like a select field, try this instead:
customfield_15400={'value': 'No'}
If that doesn’t work, use the option ID rather than the visible value. Hit the /rest/api/2/field endpoint to grab your custom field’s ID and see what values it accepts. You can also check the field setup in Jira’s admin panel - it’ll show you the exact values and whether they’re case sensitive.
Everyone’s giving you the manual fix (use {‘value’: ‘NO’} instead of “No”), but honestly? This API headache is why I ditched custom scripts for Jira stuff.
Jira’s API is a pain. You’ll fix this field, then hit another custom field with different requirements. Then you’re dealing with auth refresh, error handling, rate limits - the whole mess.
I switched to Latenode for these automations. It handles Jira’s API weirdness automatically, has built-in error handling, and you can map data visually instead of fighting field syntax. When your team adds new custom fields, you just update the flow - no rewriting Python code.
Connect your data source to Jira, map fields visually, done. No more guessing object structures or digging through REST docs.