Build safer, smarter integrations with service accounts

[#1]

Hello, Atlassian Community!

I'm Sophie Jasson-Holt, the lead content designer for the service accounts feature. I’m excited to announce the release of service accounts. For the last year, I’ve been working with product designers, engineers, and product managers, along with speaking to customers to make service accounts available to you.

Who can use service accounts?

If you're an Atlassian admin who manage your users at the organization level, then the service account feature is available to you. 

How service accounts work for you

Service accounts are designed to transform how you securely automate tasks and manage integrations across Atlassian apps.

A service account is an Atlassian account that is not associated with a person, a non-human account. Service accounts let your external apps and automated processes authenticate and interact with Atlassian apps using API tokens.

What you can do with service accounts

• Secure authentication: Use API tokens for secure communication

• Granular permissions: Control access to Jira projects, and Confluence spaces

• Audit and monitoring: Track all service account activities through detailed logs

How to use API scopes

Service accounts use API scopes to define exactly what your integrations can and cannot do. Choose only the scopes your integration needs to maintain optimal security. You can modify these permissions at any time through your account settings.

For a complete list of available scopes, see:

• Jira REST API scopes

• Confluence REST API scopes

How to get started

1. Create a service account in Atlassian administration

2. Choose your authentication method:

   • Generate an API token

3. Select API scopes based on your needs

4. Connect your applications to Atlassian apps

What subscription plan do you need for service accounts?

You'll get 5 free service accounts to start. Need more? Upgrade to:

• Atlassian Guard Standard: Up to 250 service accounts

• Cloud enterprise: Up to 1,000 service accounts, plus priority support, custom integrations, and SLAs

Share your experience

Feel free to drop your thoughts and questions about service accounts in the comments below! We'd love to hear from you.

Sophie Jasson-Holt

[Sami Shaik]

This is a much-needed enhancement for enterprise-grade governance!
 
Introducing service accounts brings clarity, control, and accountability to integrations specially in environments with strict audit, compliance, and access policies.

Being able to assign API tokens to non-human accounts and monitor usage independently of personal user tokens is a game changer for scaling automation and maintaining security hygiene.

Looking forward to seeing broader adoption across products and additional controls like expiration policies and permission scopes. Great work, Atlassian! 

[Anwesha Pan (TCS)]

This is a great article to give a head start for service accounts!

Thanks for sharing @Sophie Jasson-Holt 🙂

[Rune Rasmussen]

This was a great surprise for us, when we found it yesterday. A feature we've been sorely missing for years.

Are there any plans to let us provision service accounts?
We control all other accounts through EntraID and all license/access giving groups are also provisioned.
So while Service Accounts are a much welcome addition, the current implementation does cause some friction with our setup and way of working.

[Jared Schmitt]

HI @Sophie Jasson-Holt 

This is a really nice and long needed addition!

Unfortunately I cannot find an API endpoint to manage service accounts. When will it be available? 

[Darryl Lee]

Hello @Sophie Jasson-Holt -

Is this available to organizations that are not on Centralized User Management? We were unable to migrate to Vortex due to number of users and groups, and I do not see the new option for Service Accounts.

Hrm. Ok, so as of Aug 11, I guess this is still "Rolling Out":

• Atlassian Cloud changes Aug 4 to Aug 11, 2025 

Curiously, in App updates in our admin.atlassian.com console, it says "ROLLOUT COMPLETE":

We are anxious to get this feature, so hopefully not having Vortex is not a blocker.

[Gary Spross (Personal)]

This is awesome! One issue I noticed is that you can't view the scopes applied to an API token post creation. Having this ability (like can be done with user specific API tokens) would be really helpful.

[Kunwardeep Singh]

Hi @Gary Spross (Personal) - Thanks for feedback. I am the Product manager on this feature , and I hear you . We will revamp our designs for our next milestone, and will take this into consideration. 

Hi @Darryl Lee - yes , We are currently on track to release this feature for non-centralized by end of October. So you'll have service accounts . 

Hi @Jared Schmitt  - Yes, we are going to update the dev docs soon. ( by next week )

Hi @Rune Rasmussen  - We currently do not support SCIM sync . But this is something on our future milestones. 

[Victor Yampolsky]

I could not use the service account for REST APIs, I have:

1. created a service account.
2. related it to jira app (user)
3. added all the simple scopes (not granular)
4. added it to all the jira related groups.
5. created a token

using postman, adding basic auth for user: the service account email, password the token, when hitting: 

https://[org].atlassian.net/rest/api/2/mypermissions?permissions=BROWSE_PROJECTS%2CEDIT_ISSUES

I got the response:

{
    "permissions": {
        "BROWSE_PROJECTS": {
            "id": "10",
            "key": "BROWSE_PROJECTS",
            "name": "Browse Projects",
            "type": "PROJECT",
            "description": "Ability to browse projects and the issues within them.",
            "havePermission": false
        },
        "EDIT_ISSUES": {
            "id": "12",
            "key": "EDIT_ISSUES",
            "name": "Edit Issues",
            "type": "PROJECT",
            "description": "Ability to edit issues.",
            "havePermission": false
        }
    }
}

when hitting:

https://[org].atlassian.net/rest/api/3/issue/[ticket id]

the response is :

{
    "errorMessages": [
        "Issue does not exist or you do not have permission to see it."
    ],
    "errors": {}
}

obviously..

what am I doing wrong? can you please direct me to a walkthrough of that particular use case? hitting REST API using service account credentials?