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; } } }

JSM Cloud REST API: Regression in customer creation endpoint - Agents now get 403 when creating port

Damiano Di Battista_tgbixw

Hi everyone,

I am facing a critical issue with Jira Service Management Cloud REST APIs regarding a workflow that used to work perfectly until recently.

Our Context & Past Workflow:
We have an automation script running with an Agent's credentials (Email + API Token). For security reasons, we absolutely do not want to elevate this integration account to Global Admin.

Until recently, the script performed the following steps smoothly:

Checked if a user existed via API.

If the user did not exist in Jira, it proceeded to create them as a portal-only customer using the /rest/servicedeskapi/customer endpoint.

Added the newly created customer to a specific Organization.

The Current Problem (The Change): Without any changes on our side, this workflow has stopped working. Now, the script fails at step 2 with a 403 Forbidden error:

 {"errorMessage":"Unauthorized to perform the requested action, JIRA Administrators global permission is required."}

If I run the exact same script using my Global Admin credentials, it works. However, using a Global Admin account for a standard API integration is a massive security risk and against our company policy.

Our Current UI Configuration:

Under global Customer Access, the setting is correctly configured to: "Don't allow customers to create their own accounts. Only agents or admins can create accounts for customers."

From the Jira UI, the Agent can still successfully add/invite new portal-only customers to the project manually.

My Question: Why did Atlassian restrict the /rest/servicedeskapi/customer endpoint to Global Admins only, completely overriding the global UI settings that allow Agents to create customers?

Since this was a working feature for non-admin accounts, is there an official, secure workaround to allow an Agent's API token to provision a portal-only customer without granting them full global admin access to the entire Jira instance?

Thank you in advance for your help!

Accepted answers

Marc -Devoteam-

Hi @Damiano Di Battista

I can't tell you exactly but portal only users (customer) management changed from per JSM space to within Atlassian Administration.

Customers are created within administration and can be added to JSM spaces.

To create user in admin you need to be Jira Administrator Global permission.

You could create a service account and grant this account the correct permissions as agent and within administration and use this user in the script.

https://support.atlassian.com/user-management/docs/manage-your-service-accounts/

This should mitigate your risk, as you can't use a service account mail address or login directly with a service account.

All comments

Arkadiusz Wroblewski

Hello @Damiano Di Battista

The 403 error happens because the customer creation endpoint (POST /rest/servicedeskapi/customer) strictly requires Jira Global Admin permissions.

While agents can create customers in the user interface, the API blocks them unless they have full system admin rights. This discrepancy is a known issue tracked under Atlassian ticket [JSDCLOUD-9396] Create Customer API should require only Service desk administrator permission and not Jira Administrator Global permission - Create and track feature requests for Atlassian products., which remains unresolved.

To workaround this, you will need to use a dedicated admin account for the customer provisioning step, or limit your integration to only adding already existing customers to organizations. I recommend adding your vote to JSDCLOUD-9396, but until Atlassian changes the permission model, global admin access is required for this specific API call.

If you have any questions, please don’t hesitate to open a ticket. Atlassian Support

Marc -Devoteam-

Hi @Damiano Di Battista

I can't tell you exactly but portal only users (customer) management changed from per JSM space to within Atlassian Administration.

Customers are created within administration and can be added to JSM spaces.

To create user in admin you need to be Jira Administrator Global permission.

You could create a service account and grant this account the correct permissions as agent and within administration and use this user in the script.

https://support.atlassian.com/user-management/docs/manage-your-service-accounts/

This should mitigate your risk, as you can't use a service account mail address or login directly with a service account.

Marc -Devoteam-

Hi @Arkadiusz Wroblewski

https://jira.atlassian.com/browse/JSDCLOUD-9396 is not relevant anymore as customer account management is not on space level anymore but in administration.

Previously custom management was per space, but thus has changed, you can add customers to a space, but management of the accounts is not on that level anymore.

Damiano Di Battista_tgbixw

Hi @Marc -Devoteam- , thank you for your insightful response!

You hit the nail on the head. Since Atlassian migrated customer management into the global administration area, it completely decoupled the API behavior from the JSM UI settings we configured for our agents.

Using a dedicated Service Account as you suggested seems like the most secure and logical path forward to avoid elevating a human user to Global Admin. I will look into the documentation you provided to see if our current subscription allows us to provision one for this automation script.

Thanks again for the great advice!

Damiano Di Battista_tgbixw

Thank you both for this very clear breakdown.

@Arkadiusz Wroblewski thanks for the crucial update regarding JSDCLOUD-9396. It makes total sense now: since customer account management has permanently moved from the space/project level to the global administration area, this is no longer a bug but an intentional architectural change by Atlassian.

Knowing that the API will strictly enforce Global Admin permissions moving forward—regardless of what the JSM UI allows agents to do—leaves us with only one secure path.

We will pivot to using a dedicated Service Account as suggested. This will allow our external script to safely hit the global administration endpoints to provision portal-only customers without exposing or elevating human credentials to Global Admin.

I appreciate your time and help in clarifying the root cause of this issue!

Welcome!

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

Quick Links

Unanswered
Groups
Help

Find more posts tagged with

jira

cloud

jira-service-management-cloud

jira-service-management