Hi Community & Atlassian Team, We are encountering a site-wide issue where calling POST /rest/servicedeskapi/request fails with a HTTP 400 error across all Service Desk projects (including a custom one that we created and PROJ - the default one) and across all request types. Key diagnostic findings from instance field enumeration: * Enumerating all 77 fields on our instance shows NO field of type com.atlassian.servicedesk:sd-customer-request-type exists. * The field customfield_10010 ("Request Type") is present as com.atlassian.servicedesk:vp-origin and attached to screens, but the canonical JSM portal request endpoint requires sd-customer-request-type. * Account agent roles (Service Desk Team) and customer creation permissions are fully verified. This appears to be an Atlassian-side schema defect or incomplete work-types migration on our site. Does anybody have any advice?

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Missing sd-customer-request-type field on Cloud instance breaking POST /rest/servicedeskapi/request

Ilya Vinogradsky

Hi Community & Atlassian Team,

We are encountering a site-wide issue where calling POST /rest/servicedeskapi/request fails with a HTTP 400 error across all Service Desk projects (including a custom one that we created and PROJ - the default one) and across all request types.

Key diagnostic findings from instance field enumeration:

Enumerating all 77 fields on our instance shows NO field of type com.atlassian.servicedesk:sd-customer-request-type exists.
The field customfield_10010 ("Request Type") is present as com.atlassian.servicedesk:vp-origin and attached to screens, but the canonical JSM portal request endpoint requires sd-customer-request-type.
Account agent roles (Service Desk Team) and customer creation permissions are fully verified.

This appears to be an Atlassian-side schema defect or incomplete work-types migration on our site. Does anybody have any advice?

Accepted answers

Piyu@Appcento

sd-customer-request-type is a Jira Service Management only field, it never exists on a plain Jira Cloud site, which is why every API call for it comes back 400 or 404. If an automation or agent tries to read or write that field on a software project, the field id is not registered in that site's field registry at all, no amount of REST retries will make it appear. The 404 plus 400 body you are seeing matches this behavior exactly. Fix, check whether the destination project is JSM or a software project. If it is software, map the request type to a plain select list or label field before the migration. If it is JSM, provision the JSM app on the target site first, then the field id resolves.

All comments

Matthew Sinclair

What is triggering the API call? I'm not able to find that in the API references. (sd-customer-request-type)

Ilya Vinogradsky

I built a custom form on a website using an AI agent. Please let me know what detailed information you need and I will get it for you.

Sami Shaik

@Ilya Vinogradsky ,

Your site is almost certainly fine. The diagnosis your agent produced is built on a field type that does not exist on Jira Cloud, and Matthew's instinct was right to question it.

What the endpoint actually wants. Per the Create customer request reference, POST /rest/servicedeskapi/request takes three things: serviceDeskId (the numeric service desk ID, not the project key), requestTypeId (numeric), and requestFieldValues, a map of Jira field IDs to values. The request type is passed as requestTypeId; it is never supplied as a custom field value. The field your enumeration found, customfield_10010 of type com.atlassian.servicedesk:vp-origin, is exactly the Request Type field Cloud uses, and it is correct as it stands. sd-customer-request-type is not a Cloud field type; your client is searching for something it will never find, and then concluding the schema is broken.

Build the call from the API, not from assumptions. Four GETs give you every value you need:

GET /rest/servicedeskapi/servicedesk lists your service desks with their numeric id.
GET /rest/servicedeskapi/servicedesk/{serviceDeskId}/requesttype lists request types with their numeric id.
GET /rest/servicedeskapi/servicedesk/{serviceDeskId}/requesttype/{requestTypeId}/field returns the fields on that request type's portal form, with fieldId and required. Only these fields can go in requestFieldValues, and every one marked required must be present.
Then POST /rest/servicedeskapi/request with {"serviceDeskId": "<id>", "requestTypeId": "<id>", "requestFieldValues": {"summary": "...", "description": "..."}} plus whatever step 3 says is required.

The 400 has a body. Jira returns errorMessage (and often i18nErrorMessage) with every 400 from this endpoint, and it names the field or value it rejected. Paste that body here and the answer is usually one line. The common ones: project key sent as serviceDeskId; a requestTypeId from a different service desk; a required field from step 3 missing; a field in requestFieldValues that is not on the portal form; raiseOnBehalfOf used by an account that only has customer permission (the reference says it is not available to those users).

One general note, since you said the client was built by an AI agent: have it generate the calls from steps 1 to 3 at runtime, not from field names it remembers. Request type IDs and form fields differ per site and per project, which is why the API exposes them.

Matthew Sinclair

Your AI Agent is likely doing it wrong.

If the specific "API" element you designated is not listed anywhere in Atlassian's documentation - it won't work.

Take a read at @Sami Shaik 's reply - you will likely find your solution there.
Leverage Rovo to help sus out what's wrong.

Don't trust other AI servers to do this - they trend to mislead due to a lot of missing nuances.

Like Sami said - build on the API - not the assumptions.

Piyu@Appcento

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

api

jira-service-management