Hello
We’re integrating Atlassian APIs with a custom GPT assistant. API requests work fine with API keys, but fail with OAuth tokens (403 / authentication errors). Since we need user-level access, OAuth is required. Looking for guidance on why OAuth fails where API keys succeed in Jira Service Management.
Issue:
-
When we use API keys, the requests succeed.
-
However, when we use OAuth tokens, the same API calls fail with 403 Forbidden or authentication required errors.
-
Example with API key → works.
-
Example with OAuth token → returns:
-
Client must be authenticated to access this resource
or
403 Forbidden
Why this matters:
-
API keys are tied to specific users, which doesn’t work for our GPT integration because:
-
OAuth is required to ensure user-level authentication, but currently it fails.
Tests performed:
with OAuth token → returns authentication error.
Any help or direction would be greatly appreciated.
Thanks,
Naveed
Hi @NaveedRafiei – Are you certain that your OAuth token includes sufficient scopes for the requests you are testing?
If I had to guess, the inconsistent behavior is a result of the API key having greater scopes than the OAuth token.
Does that seem possible?
I should add that this test scenario can be common, because API tokens are often created with full permissions (un-scoped) by default:
Hi,
I would like to point out that, in my case, it’s not that requests fail when using an OAuth token, it is the very process of getting the token that fails.
When I click the “ Sign in with api.atlassian.com
” button in ChatGPT, I get redirected to a page that looks like this:
Which doesn’t seem to be the case for everyone. Please note that I’m a “regular user” of Jira Service Desk, and not a “support agent” – I can only act on my tickets.
Hi @GabrielRoyLortielogi - I’m sorry to hear you’re facing this issue. It’s possible that the error is related to the fact that you do not have an agent license. Agents are actually the “regular” users in Jira Service Management/Desk, and non-agents (developers) can be thought of as “lite users”.
Hi @AaronMorris1
Gabriel does not have an agent license, but that shouldn’t be the issue.
The main reason for opening the request with Atlassian was to ensure that users without agent licenses can view their own requests or those in which they are participants. Atlassian support was unable to provide a solution and advised me to seek help from the forum.
If Gabriel can see request X in our Jira Helpdesk, he should also be able to see the same request via the ChatGPT API after authentication has been completed.
Hi @NaveedRafiei – First, thank you for the clarification! It wasn’t clear that Gabriel’s comment was associated with yours. It seemed (to me) as though he was another user from another organization that had a loosely similar issue and was just adding to your thread. 
That being said, I am now confused as to the exact issue you would like help troubleshooting. You initially reported an inconsistency between API Tokens and OAuth Tokens, and I replied with a question about scopes. But now Gabriel is reporting that the problem is that he can’t even request an OAuth token?
Which scenario are you troubleshooting?
Hi @AaronMorris1
With my Agent license, I get access, but a user like Gabriel, who has a User license, gets access denied. I’ll talk to my colleague Anabelle to share her experience here as well so you can better understand the issue, she’s a developer, whereas I’m in IT. She can explain it more clearly.
Hi @AaronMorris1 I’m working on this issue with Naveed and Gabriel.
What works:
- Calling the API with a unscoped token
What doesn’t work:
- Calling the API with OAuth. We set up OAuth using an Atlassian “developer app” built here: Developer console
What I tried:
- Based on your suggestion, I tried setting up a scoped API token. The endpoint we are testing with is GET **/rest/servicedeskapi/request/{issueIdOrKey} (**https://developer.atlassian.com/cloud/jira/service-desk/rest/api-group-request/#api-rest-servicedeskapi-request-issueidorkey-get) , which needs these scopes:
read:servicedesk-request
, read:request:jira-service-management
, read:user:jira
- However the scope read:servicedesk-request does not exist in the list when creating a scoped API token.
- If I create a scoped token with the scopes that are available (
read:request:jira-service-management
, read:user:jira
) the GET request returns 401 Unauthorized
We also found another issue today where I can’t actually see the instance I’m scoping for on the OAuth page. Ex I scoped my developer app to access the jira service management API but in the dropdown to select an instance the only option I see is our jira instance (the jira service management instance is not there).
2 Likes
Hi @annabellesauve – Thank you! This explanation is helpful.
Regarding the 401 Unauthorized
error with the scoped token – Which URL format are you testing against?
- https://{my-domain}.atlassian.net/rest/servicedeskapi/request/{issueIdOrKey}
- https://api.atlassian.com/ex/jira/{cloudId}/rest/servicedeskapi/request/{issueIdOrKey}
For scoped tokens, you need to be using the second format…so just double-checking.
Regarding scopes – Using Postman, I confirmed that the following scopes are the only ones needed to view a service desk ticket using the API:
- read:request:jira-service-management
- read:user:jira
I, too, observed that the read:servicedesk-request
classic scope is not available for selection. But I think it is unnecessary when we use the granular scopes instead.
Regarding the selection of a Jira Service Management instance on the OAuth page…I don’t believe there is usually a distinction between Jira and Jira Service Management on this screen, so probably the Jira site that you see is correct.
Hi @AaronMorris1
Thanks for the response! I was indeed testing with domain.atlassian.net. I tested the scoped token again but with api.atlassian.com and this time I got a 403 Forbidden. Is there a reason why I would be able to look up the ticket directly in our helpdesk, and look it up with a general (no scope) API token, but not a token that has been scoped specifically for that request?
The way our organisation is set up there is a distinction. We have a domain just for Jira and a separate domain for JSM and confluence together. And in fact when I do a scoped OAuth developer app for confluence I see the other domain. But if I scope for jira service management the domain is not in the dropdown.
Hi @annabellesauve –
Unfortunately, there seems to be something about your setup that I don’t understand.
What I can say is that the only way I have been able to reproduce a 403 Forbidden
error is by using a valid API token from an unlicensed user. However, I did not see a difference between using scoped or unscoped API tokens. They both either worked or didn’t work based on the licensing.
Testing with a valid API token that has insufficient scopes results in a 401 instead of a 403, and so I don’t think your 403 error is a scope problem.
That said…
This description is a bit confusing, given what little I know about your setup. So to clarify, does this mean you have two different atlassian.net domains like this:
Meaning, are they two different sites to manage in the Atlassian Admin portal (https://admin.atlassian.com/)?
Hi @AaronMorris1 , we have a single organization, Jira Software and Confluence are in our organization’s list. The only difference is that I can manage or invite someone to Jira without going through our company guard. As with Bitbucket, for example. Our Confluence and JSM have the same URL, but Jira Software Cloud does not. I don’t know if that answers your question. That being said, in my connected application permissions, I don’t see Annabelle’s request in our Confluence instance, but I do see it in our Jira Software Cloud instance. Is this possibly related, but we don’t plan to pair all our applications anytime soon. That will be a project in itself and is not planned for the near future.
Hi everyone – It feels like there’s probably something about your site configuration that is likely causing confusion or problems with user permissions and OAuth.
For example, it is still unclear if you have two different Atlassian Cloud sites inside the same Atlassian organization, if you have a single Atlassian Cloud site that uses a custom URL for JSM and Confluence, or some combination thereof. It’s also unclear if “company guard” refers to Atlassian Guard, which, of course, also adds complexity.
However, I also understand you’re probably being cautious about sharing details in a public forum like this.
With all that being said, I suggest you either:
- Submit a support ticket to Atlassian Developer Support: https://developer.atlassian.com/support
- Send me a private message if you feel comfortable continuing this conversation with me privately.
Otherwise, perhaps someone else in the community may chime in with better insight.
Hi Aaron.
It’s good if we can talk. I’m not very familiar with this forum. Are you part of the Atlassian support team?
How can we get in touch and have a conversation?
Hi @NaveedRafiei – No, to be very clear, I am not an Atlassian employee and not part of the Atlassian Support team. No one in this forum is associated with the Atlassian Support Team (to my knowledge).
This is a community forum for people who develop on the Atlassian Platform and make use of Atlassian’s various public APIs, libraries, and other interfaces. Here’s the official “Welcome” topic that explains it better: https://community.developer.atlassian.com/t/welcome-to-the-community/84
There are some Atlassian employees (not from Atlassian Support) who unofficially monitor certain sections of the forum to support the development community. Sometimes they’ll chime in if they notice a question they can help with. But most of the forum participants are developers or system admins from non-Atlassian companies that use the Atlassian platform (like you and me).
If you want help from the Atlassian Support Team: Please use the Developer Support link I shared above. That’s the only way (AFAIK) to get attention from an Atlassian employee who is paid to support the developer community. But of course, SLA times can vary. Sometimes answers come fast, and sometimes they take weeks.
If you still want community support (for example, if you already tried Developer Support or if they are taking too long), then feel free to continue posting details in this thread. And if you are worried about sharing details publicly, feel free to message me (or another community member) privately. You can send private messages by accessing my profile and pressing the Message button.
Perfect . thanks for your help. i just opened a ticket with Atlassian Developer Support team.
Have a nice day
1 Like