Summary

This article explains the JSON data required to set the customer request type when creating an issue via the /rest/api/2/issue REST endpoint (from Jira).

Read the caveat section on the end for a heads-up comparison to Jira Service Management API.

Environment

Jira Core 7.x and 8.x with Jira Service Management 3.x or 4.x.

Solution

• To set the request type via REST API, you will have to use the custom field ID for the Request Type custom field.

• For example, if the request type custom field in your instance has the id of 10202, you will have to use customfield_10202.

• As for the value, it is actually a combination of the project key with the values of the KEY column in the AO_54307E_VIEWPORTFORM table

  • Examples of valid values: 

    sda/getithelp
    sda/cc54f9a4-11bc-4783-a32e-382ff1840eb2

  • Note that if a project was renamed, the Customer Request Type value will be prefixed by the original project key instead.

  • Alternatively, you may create the desired type of issue through the service project portal and copy the value from the Customer Request Type it has:

    select v.stringvalue
    from jiraissue i
    join project p on p.id = i.project
    join customfieldvalue v on v.issue = i.id
    where p.pkey = 'SDA' and i.issuenum = 1234; -- replace by the issue key recently created

• Make sure that the Customer Request Type is added to the create issue screen. 

• Here is a sample JSON data which works

  {
      "fields": {
          "project": {
              "id": "10205"
          },
          "summary": "Something's wrong",
          "issuetype": {
              "id": "10100"
          },
          "priority": {
              "id": "1"
          },
          "components": [
              {
                  "id": "10000"
              }
          ],
          "customfield_10202": "sda/getithelp"
      }
  }

• You'll just have to identify the custom field id and valid values and you should use for it to work.

Caveat

Jira Service Management allows you to set hidden fields with default values for each Request Type.

Creating issues through Jira's /rest/api/2/issue endpoint will not follow those configurations and proceed accordingly to what was set on the json only. This may not be desired as it may result in API-created issues diverging from the portal-created ones and will add overhead when needing to set additional hidden values to the request types.

You may want to consider using Jira Service Management REST API /rest/servicedeskapi/request instead — this endpoint will inherit the hidden fields default values configurations for the given Request Types.