Jira Automation Send Web Request returns 400 on POST /rest/servicedeskapi/request incorrectly

[Federico Frade]

I am using a Jira Automation rule that triggers a Send web request action with a POST to /rest/servicedeskapi/request. The request body is valid JSON and works correctly when sent to an external endpoint (webhook.site), but consistently returns HTTP 400 with the following error when targeting the JSM endpoint:

Send Web Request:

Unable to publish the web request - received HTTP status response: 400

Error found in the HTTP body response:

{"errorMessages":["There was an error parsing JSON. Check that your request body is valid."]}

Request body used:

{
    "serviceDeskId": "1406",
    "requestTypeId": "2292",
    "requestFieldValues": {
      "summary": "{{issue.summary}}",
      "description": "{{issue.description}}"
    }
}

I have also tried this same request from postman and the issue is created.

What I have verified:

• The JSON is valid and parses correctly

• The same body sent to webhook.site returns 200 with the full payload intact

• The same request from Postman creates the servicedesk ticket

• serviceDeskId and requestTypeId are correct and verified via GET /rest/servicedeskapi/servicedesk and GET /rest/servicedeskapi/servicedesk/1406/requesttype/2292/field

• Smart values ({{issue.summary}}, {{issue.key}}, etc.) are resolving correctly as confirmed by webhook.site logs

• The issue is specific to Jira Automation's Send web request — the same request works when executed manually via HTTP client

Expected behavior: The automation rule creates a new JSM request successfully.

Actual behavior: Returns HTTP 400 — JSON parsing error, despite the body being valid.

Instance: dss-satellogic.atlassian.net
Plan: Premium

[James Gamble · Accepted solution]

Hola Federico,

Given that the same request works from Postman and your authentication is already confirmed, I'd concentrate on what Jira Automation substitutes into the body at runtime. Your testing already narrows this down quite a bit: the endpoint, serviceDeskId, requestTypeId, and credentials are working, while Automation is the variable at issue.

The first test I'd run is the one @Andrea Robbins suggested: temporarily replace the description with a fixed value such as "description": "test". If that succeeds, you've isolated the problem to the rendered Description smart value rather than the request itself.

If it does, change the body to use JSON encoding for both text fields:

{
"serviceDeskId": "1406",
"requestTypeId": "2292",
"requestFieldValues": {
"summary": "{{issue.summary.jsonEncode}}",
"description": "{{issue.description.jsonEncode}}"
}
}

Automation substitutes smart values before sending the HTTP request. A description containing a quote, newline, backslash, or other special character can therefore render an otherwise valid JSON template invalid. Sending the body to webhook.site proves the payload was transmitted, but it doesn't necessarily prove the substituted body meets the JSM endpoint's JSON parsing requirements. Atlassian specifically recommends jsonEncode when including text fields in outgoing JSON web requests.

I'd also make sure the Send web request action has Content-Type set to application/json. Accept: application/json controls the response format, while Content-Type tells the JSM endpoint how to interpret the request body.

If the fixed description works but jsonEncode still returns the same 400, try logging {{issue.description.jsonEncode}} immediately before the web request and compare the resulting text with the successful Postman payload. Atlassian also has a specific KB covering Description fields in Automation web requests and recommends JSON encoding when special characters or formatting are present.

If even a hard-coded "description": "test" produces the 400, could you share a screenshot of the complete Send web request action, particularly the HTTP method, Web request body setting, Content-Type header, and the exact URL? At that point, the description probably isn't the culprit.

Thanks,

James

[Andrea Robbins]

Agreed - there could even be a special character in the summary (doubt it but possible) if you hard coded that too for testing.

[Duc Thang TRAN · Accepted solution]

Hello @Federico Frade 

If your description contains special characters that Jira Automation cannot interpret correctly, you may encounter this error.

Try using:

"description": "{{issue.description.jsonEncode}}"

On my case test with this description and got same error 

L'utilisateur rencontre l'erreur "Accès refusé" sur le dossier C:\temp

Hope this can help 

[Andrea Robbins · Accepted solution]

I agree that it is likely related to the description. In postman, you likely pasted it as a string with no issues but the smart value is possibly (not to the human eye) but to automation in a different format than what it wants. 

If you can retest and remove the description, it will help to isolate the issue. Everything else looks great. 

[Marc -Devoteam- · Accepted solution]

HI @Federico Frade 

On the web request action in the authorization of the call, is the email:apikey converted to base64 and noted as Basic <result of the conversion>

Example:

[Federico Frade]

Yes, it is; in fact, at one point when I had this set up incorrectly, the error was a 401.

Looking at your screenshot, I saw that you had the "Accept: application/json" header set, and I have the "Delay execution of subsequent flow actions until we've received a response for this web request" option checked, so I add this header, but even after that, it still returns the same 400 error.

[Federico Frade]

Hi, thanks everyone for your replies! I'm new to using this forum and never imagined I'd get so many responses so quickly.

To summarize: I managed to solve the issue by using the trick of applying 'jsonEncode' to the 'summary' and 'description' fields. I was also using other 'custom_values' and spent some time figuring out how to send them; I used the following endpoint:

GET /rest/servicedeskapi/servicedesk/{sd_id}/requesttype/{rt_id}/field

The problem was that I was using the value field ​​listed there as options, whereas I actually needed to send the labels.