How to add custom field values when creating Jira tickets through REST API

Other Questions Jira
1

I’m trying to create a new issue in Jira using the REST API and I need to include a custom field in my request. I have a dropdown custom field that I want to populate during issue creation but I’m not sure about the correct JSON structure.

The custom field is a select list type with these details:

"customfield_10125": {
  "required": false,
  "schema": {
    "type": "option",
    "custom": "com.atlassian.jira.plugin.system.customfieldtypes:select",
    "customId": 10125
  },
  "name": "Priority Level",
  "hasDefaultValue": false,
  "operations": [
    "set"
  ],
  "allowedValues": [
    {
      "self": "http://mycompany/rest/api/2/customFieldOption/10201",
      "value": "High",
      "id": "10201"
    },
    {
      "self": "http://mycompany/rest/api/2/customFieldOption/10202",
      "value": "Medium",
      "id": "10202"
    }
  ]
}

What’s the proper way to structure this in my create issue JSON payload?

2

just hit this yesterday! I was using /rest/api/2/issue instead of /rest/api/3/issue and kept getting validation errors even tho my JSON was fine. check your endpoint first. also, your auth headers might be the issue - custom fields sometimes need different permissions than regular fields.

3

Custom field behavior varies a lot between cloud and server instances. Same JSON payload worked perfectly in dev but failed in production because of different Jira configs. For your select list field, both approaches work, but I’d test with a simple POST first:

{
  "fields": {
    "project": {"key": "PROJ"},
    "summary": "Test issue",
    "issuetype": {"name": "Task"},
    "customfield_10125": {"id": "10201"}
  }
}

Field context restrictions caught me off guard. Your custom field might only show for specific projects or issue types, which makes requests fail silently or throw weird errors. Check the field context settings in Jira admin if you’re getting validation failures that don’t make sense.

4

Been down this rabbit hole countless times. Yeah, you can manually craft JSON payloads for Jira custom fields, but what about validation errors, retry logic, or dynamic field mapping?

I used to write custom scripts for every Jira integration until I realized I was rebuilding the same stuff repeatedly. Field contexts change, API versions update, and your hardcoded JSON breaks in production.

The real issue isn’t syntax - it’s building reliable systems that handle edge cases. Custom field value doesn’t exist? Permissions change? Need to populate multiple fields from external data?

Latenode handles this complexity automatically. Visual workflows populate custom fields, handle errors gracefully, and adapt to different Jira configs without code. Plus it connects with other tools - databases, spreadsheets, APIs.

You focus on business logic instead of debugging JSON structures. Way more productive than maintaining custom scripts.

5

To include a select list custom field when creating a Jira issue via the REST API, you should structure your JSON payload to reference the custom field ID along with the ID of the desired option. Here’s an example of how your JSON should be formatted:

{
  "fields": {
    "project": {"key": "YOUR_PROJECT"},
    "summary": "Your issue summary",
    "issuetype": {"name": "Task"},
    "customfield_10125": {
      "id": "10201"
    }
  }
}

Using the ID for the option is recommended since it remains consistent, even if your Jira configuration changes. Make sure that the custom field is compatible with the issue type and project you are using.

6

I’ve been working with Jira integrations for years. The manual REST API approach works, but it gets messy fast with multiple custom fields and complex workflows.

For your case, you can use either ID or value:

{
  "fields": {
    "project": {"key": "PROJ"},
    "summary": "Test issue",
    "issuetype": {"name": "Task"},
    "customfield_10125": {"value": "High"}
  }
}

Once you scale this up with different projects, custom field mappings, error handling, and dynamic field population, you’ll spend more time debugging JSON than solving real problems.

I switched to Latenode for our Jira automations. It handles the API complexity and lets you focus on business logic. You can build visual workflows that auto-populate custom fields based on triggers, validate data before sending, and handle errors gracefully.

No more wrestling with field schemas or worrying about API breaking changes. Just drag, drop, and configure.

7

I’ve worked with multiple Jira instances and there’s actually some flexibility in structuring custom field payloads. The previous answers show the ID approach, but you can also reference by value - sometimes more readable:

{
  "fields": {
    "project": {"key": "PROJ"},
    "summary": "Issue with custom field",
    "issuetype": {"name": "Bug"},
    "customfield_10125": {"value": "Medium"}
  }
}

Here’s what I learned the hard way: always validate your custom field config first. Different Jira versions and setups behave differently with select lists. I make a GET request to /rest/api/2/issue/createmeta to verify the exact structure for that specific project and issue type. This saved me tons of debugging time when custom fields weren’t available for certain issue types or had different validation rules.