Your top 3 asks on Jira Service Management extensibility

Hello JSM Cloud app partners,

I’m a PM on the Jira Service Management (JSM) ecosystem team. I would love to understand your top 3 asks as it pertains specifically to JSM extensibility. In order to get focussed responses, please do not include other topics such as Forge, Jira platform extensibility, pricing, general ecosystem needs, and so on.

I’m really looking for your top asks for REST, UI endpoints, and use cases you would like to see enabled from a JSM extensibility standpoint. So things like more APIs at and UI extension points at About Jira Service Management modules (bottom of this page) would be quite relevant.

Looking forward to your responses!

Thanks so much for your feedback,


Hi Abhinaya,

we do indeed have a few things that would help us a lot, as we use JSM APIs quite a lot for our app.

  1. JSM portal currently uses a lot of private APIs to get most of the information, it would be really helpful to have most of them public. E.g. information that is currently missing from the public APIs:
  • Portal announcement message
  • Portal customizations (e.g background image)
  • Service Desk descriptions + images
  • Request type group description texts
  1. Expose an API that allows retrieving a list of “Services” (ITSM) for a request type/service desk. Currently, we cannot create requests with the API because there is no way to get a valid list of services

  2. Have an API for getting approval information, e.g. fetching possible approvers (see [JSDECO-190] REST API to retrieve possible Approvers - Ecosystem Jira)

Thanks for considering, happy to walk you trough these requirements in a call or give you more details in a doc!


1 Like

Hi @tobias.viehweger thanks for the feedback. I understand 3 but would like to understand 1 and 2 more. I’ll reach out to you to set up a call.

1 Like

We need to use JSM Insight REST APIs from our Connect apps but currently they support only the Basic authentication (with user email and API tokens).

Please make the authentication consistent with all other Jira Cloud REST APIs and support JWT authentication and user-impersonated OAuth2 tokens. See also comments by others in [JSDCLOUD-9879] REST API for Insight JSM Premium Cloud - Create and track feature requests for Atlassian products.

Kind regards,

  • Satisfaction comment should be available as a part of the ticket, not a separate request

not extensibility but core functionality:

  • multiple gadgets per sprint
  • reporter’ email should be easy to see/copy

those two aboe are REAL pain

Hi @AbhinayaSinha
That would be great if you could add below api’s/locations:

  1. (Customer Portal) REST API to control the visibility of request types
  2. (Queues) Custom bulk operation to perform some operation on selected issues

We are ready to discuss our needs during the call if you like.

Appsvio Team

Thank you @raimonds.simanovskis. I’ve passed your message to my colleague who works on Insight.


  1. ADF support for comment/description-related REST APIs It’s currently a hassle to send comments in ADF, you have to post the comment in JSM API, then update it in the Jira Platform API with the ADF you want.
  2. APIs to edit the templates for customer emails. For our Read Receipts app, we need the JSM project admin to add the snippet to the email template that contains the tracking pixel. It’d be great if we could do that for the admin.
1 Like

we would love

  1. to replace the default Customer Portal to offer a custom experience (think of it like a generalPage module for JSM). An administrator could choose which custom-portal (offered by installed apps) to use for his service desk. Could work like Confluence themes.
  2. to control the request types a user is able to use
  3. access the JSM Insight REST APIs


Hello @AbhinayaSinha,

Thanks for taking time to get feedback from us, we have been reporting subjects for a while now and some have been stuck without any answers.

Here are our main subjects:

  • Our Elements Connect for Jira Cloud integrates inside the Create Request form on JSM portal. It provides select list with options coming from external datasource. We need to have dependencies with Jira fields to have issue context. In a JSM context, we would love to be able to register on public events send by JSM on frontend so our select lists can refresh live.
    Events would be fired every XXXms on user input changes.'JSM_FIELD_VALUE_CHANGED' , function(context) {
// context = {
//       fieldId: 'summary',
//       oldValue: 'Hello ',
//       newValue: 'Hello World',
// }

More details have been provided on this Confluence page

  • Be able to integrate at any locations inside the Create Request form on JSM Portal (not only at the bottom). See created issue
  • Be able to add issue properties on JSM Create Request REST endpoint so app can set values on request creation
  • Be able to update request type on existing request via REST API

Do not hesitate to come back to me if you need more details about all these improvements / features.

Have a nice day,

Hey Raimonds,

Firstly, long time no speak! Thanks heaps for your recommendation.

The Insight team is currently putting together a plan to engage with the APIs via JWT and OAuth2. We will have more to say about this in the new year.

We rolled out with basic authentication in order to deliver some value to customers faster. We recognise that we would need to fix this in the future.

Thanks again!

Hi @valente ,

I second @raimonds.simanovskis 's request for JWT (Connect) authentication, and also eventually Forge authentication for the Insight API.

We also need access to the SLAs and Calendars through the REST API.


1 Like

Thanks for your feedback. Will get back to you in case we have questions.

Hi Jullian, thanks for your feedback. With regards to controlling the request types a user is able to use, we’ll first need to build this on JSM cloud. The functionality does not exist today. About accessing Insight REST APIs, @valente has responded on this thread.


we have an app that creates customers from a service. Since we don’t have any info on the customers, we create it with some minimal information. We would like to be able to edit those customers later on. So, options to edit customers. Can be easily managed with a PUT on
Don’t know if there are any drawbacks here or why it isn’t implemented already.

Also, I’d personally like a bit more attention on the JSM part of this community as a lot of posts go unanswered…

Thanks in advance

Hi @BriceGestas,

With regards to your ask on being able to update request type of existing request, please take a look at JIRA Service Desk Ecosystem - Issues - Ecosystem Jira Does it address your need?

Hello @AbhinayaSinha,
I forwarded the link to the concerned team, they will have a look at it.
I will get back to as soon as I know :wink:
Thanks a lot

Hi I think there are a few low-hanging fruits that would improve JSM extensibility a lot at least for my use case.

I provide pre-configured projects with fields and workflows to help automate various specific business tasks. Unfortunately, I am quite restricted with the Service Desk API and might need to basically redevelop things like the queues view and the request forms because some API endpoints, while very simple and existent for a good time now (meaning that they are unlikely to change) are simply not published. I tried accessing them via user impersonation but I am encountering 401 errors even though the oauth token of my connect app is working properly. Committing to these endpoints and making them public would in my view enable more business use cases for Jira, something that I believe is aligned with Jiras long-term goals given how many different templates you already have. Here my top asks

  1. Provide a more complete Create/Update Request Type API endpoint that allows updating fields not just based on the field configuration since that makes a few features such as attachments (which can’t be made required) or non-required fields impossible. As far as I can see there is already a simple private API that is used when using the UI, all you would need to do is document and publish it. Assigning request types to groups is also a fundamental feature that I am missing from the request type API.
  2. Publish the API for creating, editing and deleting queues.
  3. I can’t decide which one is more important but I have two more APIs that I would like to have access to. Allowing to edit customer notifications would be another very simple task since the API for this is very simple. On the other hand, editing and creating new SLAs would also be useful but there are more options to this and it will be a bigger task to document it and handle invalid requests.

I would be happy to help out with the documentation and testing of these endpoints if that would make them available sooner.


Hello @AbhinayaSinha,

Our team has implemented the desired feature with the proposed workaround, thanks a lot :+1:

Did you had a chance to look at our other asks ?

Thanks for your feedback

Is anyone from Atlassian here ?