Hi, I am trying to use the new Granular API Tokens (API key with scopes) for an integration, but I am facing a visibility issue.
The Scenario:
- Endpoint:
GET /rest/api/3/project (or /search)
- User: Site Admin (has full access).
- Goal: List all projects in the instance (including JSM projects).
The Problem:
- When I use a Classic API Token (Basic Auth: Email + Token), the endpoint returns 148 projects.
- When I use a Granular API Token (Bearer Auth), the endpoint returns an empty array
[] (or 404 when querying a specific key like /project/KEY).
What I have tried:
I created a token with 50+ scopes, including every possible combination of:
read:project:jira
read:user:jira (and read:account)
read:application-role:jira
read:permission:jira
read:instance-configuration:jira
read:servicedesk-request:jira-service-management (since we have JSM projects)
Debugging results:
- I checked
/rest/api/3/mypermissions?permissions=BROWSE_PROJECTS using the Granular Token, and it returns havePermission: true.
- The token works for creating issues (
POST /issue), so authentication is successful.
Question:
Why does the Granular Token return an empty project list despite having read:project:jira and BROWSE_PROJECTS permission? Is there a hidden system scope required to “see” the projects list that Classic Tokens have by default?
Thanks for any help!
Hi @izimen ! I hope you are doing well! Here’s how you can fix this!
When using an api, it must be a specfic format, like so -
Classic (unscoped) token URL:
https://yourdomain.atlassian.net/rest/api/3/project
Scoped (granular) token URL — use this one:
https://api.atlassian.com/ex/jira/{cloudId}/rest/api/3/project
You can get your cloud id by doing the following url as a GET request
https://api.atlassian.com/oauth/token/accessible-resources
As always, also ensure you auth your requests!
Basic auth also can work aswell.
Hope this helps!
Hi,
I updated my setup to use the API Gateway URL: https://api.atlassian.com/ex/jira/{cloudId}/rest/api/3/.
Despite having 50+ scopes enabled (including read:project, write:issue, read:application-role, and read:permission), the results are inconsistent:
-
GET /myself returns 401 Unauthorized with error: 401 - “Client must be authenticated to access this resource.”
-
GET /project returns 200 OK but an empty array []. The user is a Site Admin, Agent, Customer and etc. with access to 148 projects.
-
POST /issue returns 401 Unauthorized with the error: “You do not have permission to create issues in this project.” This was tested on a project where the user is a Project Admin.
Tested on JSM and Jira Software projects with Header and Basic Auth.
All these operations work perfectly when using a Classic API Token via Basic Auth on the direct {site}.atlassian.net URL.
It appears Granular User Tokens fail to inherit project-level permissions or visibility when routed through the Gateway. Is there a specific system scope required to “unlock” project access that is missing from the standard scope selection list?
Thanks for any insights.