Unable to create any JSM Change requests – ProForma endpoint returns HTTP 400 Invalid request payloa

Vivian Duong

We are currently unable to submit any Change request types in our Jira Service Management Cloud project.

When attempting to submit a Change request, the user receives:

“We couldn't create your work item. Please try again later.”

This is affecting all of our Change request forms, rather than one specific request type/form.

We investigated the failed request using browser Developer Tools and found that JSM is making the following request:

POST /rest/proforma/internal/1/issue

The request returns:

HTTP 400 Bad Request

Response:

{"errorMessages":["Invalid request payload. Refer to the REST API documentation and try again."]}

The submitted payload contains the expected project, issue type, request type and ProForma/JSM Form information. One example includes:

issueType.id: 10006

requestTypeId: 228

The request also contains a form object with fieldAnswers and a valid templateFormId.

We have confirmed that Jira Service Management currently reports operational status. We also observed that Jira's status page has shown differing status for the Create and edit component, so we'd like Atlassian to confirm whether there is a known platform-side issue that could cause JSM Forms/ProForma issue creation requests to return this HTTP 400 response.

Oliver Bennett_cte8ed

The fact that every Change request is failing with the same 400 response makes a form-specific configuration issue less likely. Since the request is reaching /rest/proforma/internal/1/issue and Jira is returning Invalid request payload, I’d also check whether anything changed recently in the Change request type, workflow, or Forms configuration.

If the payload looks valid for several different forms, I’d capture one successful request from another issue type and compare the two payloads. If those look consistent, this feels more like a JSM/ProForma backend issue than something specific to a single form. Checking Atlassian support with the affected project, request type IDs, timestamp, and the failing request ID should help them trace the 400 on their side.