Web Request with Token Generated by Service Account: Authentication Fails

[Kent G]

I'm doing the most basic thing that every company does (I assume). Entra is creating User records in an Assets schema. I added a custom attribute named "Atlassian Account ID" of type User. I wrote an automation I've used dozens of times to populate that field. On create of an asset User record, it sends a web request to get the users Jira User object based on their E-mail Address and puts it into the "Atlassian Account ID" field.

Works perfectly as always...using a token generated by me, using my Atlassian account.

But we all know that's not great. The token should be generated by a service account. And in an effort to avoid asking my AD guy to create a bot account with a company email address, I'm using an Atlassian Service account. After all, that's what they're for!

However, when I change the Authorization to use the token generated by the service account, no dice. This appears in the web response: X-Seraph-Loginreason=[AUTHENTICATED_FAILED].

Oh believe me, I've tried and tried. Yes -- the Service Account has every app permission I have and is in every group I am in. I even gave it org-admin -- it doesn't appear when you look at the members of the org-admin group, but a popup in the corner said org-admin was successfully granted when I gave it. Yes -- I'm base64 encoding the tokens. Yes -- to some other third thing because listing only 2 things sounds awkward.

I've spent several hours diagnosing with Claude, and here was its final conclusion based off screenshots of the automation audit log showing the Web Response using each token:

---

Despite all the permissions you've granted, the service account token is still failing authentication against the Jira REST API. Your token (image 1) has no such header and succeeds perfectly.

This confirms definitively what I theorized earlier: the @ServiceAccount.atlassian.com account type cannot authenticate against the Jira REST API using Basic Auth, regardless of permissions. The permissions are irrelevant because it never gets past authentication in the first place.

This is an Atlassian architectural limitation, not a configuration problem. You have proven it exhaustively:

• Same endpoint
• Same rule
• Same permissions
• Same scopes
• Only difference is account type
• Result: your account authenticates, service account fails every time

You are done investigating. There is nothing left to try. The bot account request is not just justified — it is the only viable path forward. The evidence you now have is unambiguous and would satisfy any SecOps reviewer.

Submit the ticket.

---

So -- before I do submit the ticket to my SecOps team to have an old-school AD bot account created -- is anyone here smarter than Claude? Does anyone have ideas how to make this work? Or whether it can work? Or whether Claude is correct and Atlassian service accounts simply cannot be used for this?

[Arkadiusz Wroblewski]

Hello @Kent G 

Atlassian service accounts can be used for Jira REST API calls. The important catch is that service accounts can only create scoped API tokens, and Atlassian says those tokens must call Jira through the platform gateway URL format, for example:

https://api.atlassian.com/ex/jira/<cloudId>/rest/api/3/...

not your normal

https://<site>.atlassian.net/rest/api/3/...

So my guess is that your working rule was built around your own personal token against the normal atlassian.net URL, and then you only swapped the token. That changes the token type, but not the endpoint format. Atlassian even has a KB for the exact pattern where a service account token returns 401 / X-Seraph-LoginReason=AUTHENTICATED_FAILED when used the wrong way.

[CLOUD-12617] Add support for atlassian.net when sending web requests with scoped API tokens to avoid permission errors - Create and track feature requests for Atlassian products.

401 Unauthorized error when service account accesses Jira or Confluence API | Atlassian Cloud | Atlassian Support