I can't figure out the permissions required to access the "projects" REST endpoints

[James_Rodgers]

I am trying to create a user access report using the REST API and I have come to a block on looking up permissions granted at the project level. These do not get factored when getting the permissions for the repo, it looks like it needs to be a separate call to the "/workspaces/{workspace}/projects/{project_key}/permissions-config/groups" endpoint for the project linked to the repo, then apply the permissions giving priority to the repo level permissions.
My problem arises in that I can't seem to find permissions that work to see the "/workspaces/{workspace}/projects/{project_key}". I have an oath2 token I have given the permissions of "project:admin" that are listed in the documentation but I still get unauthorized. I also have a workspace access token but the documentation for that is unclear to me, it shows "read:project:bitbucket" but there is no "bitbucket " listed where you grant permissions so I'm not sure what that means. Adding a workspace token with "project:admin" also didn't work.
Has anyone gotten this to work or is there an alternate path to see the project level permissions granted to a user to access a repository?

[Arkadiusz Wroblewski]

Hello @James_Rodgers 

Probably easiest will be user-based API token from a dedicated account that has explicit Project Admin permissions and a Projects:Read scope.

Best,

Arkadiusz 🤠 ☀️ 

[James_Rodgers]

Thank you for responding.
My understanding is that user API tokens have been deprecated, I see nowhere to create a user API token. the app password model is in brown out right now and new tokens are not possible.
In further troubleshooting this I was able to make a project level api token which was able to get the endpoint `https://api.bitbucket.org/2.0/workspaces/{workspace}/projects/{project_key}' but it still get's 'Forbidden' when trying to get the permissions endpoint, 'workspaces/{workspace}/projects/{project_key}/permissions-config/groups' .
From what I can see this is a piece of the permissions that is unreachable by the current API.

[Arkadiusz Wroblewski]

@James_Rodgers 

If I wanna to be honest, don't waste time into too much troubleshooting. 

You are on premium Subscription, so Open Ticket under support.atlassian.com 

Atlassian Support see also backend, so they have much easier to troubleshoot.

Best,

Arkadiusz 🤠 ☀️ 

[Ron Votazz]

Hi @James_Rodgers ,

You're hitting two separate things — a scope issue and a permission issue — plus a confusing bit of naming.

1. You don't need admin to read permissions. With the API-token scope model, all three endpoints (permissions-config/groups,
permissions-config/users, projects/{key}) are covered by read:project:bitbucket — Atlassian defines it verbatim as "Allows
viewing of project and project permission data." admin:project:bitbucket is only for create/update/delete, and it does not
implicitly grant the read scope — so if you ticked only Admin, reads will fail. (docs)
(On the older OAuth 2.0 consumer model it's asymmetric: permissions-config reads need project:admin; plain project isn't
enough.)

2. The "no 'bitbucket' checkbox" confusion. The …:bitbucket strings are internal scope IDs — the token UI never shows them.
It shows checkboxes that map to them:
- Projects → Read = read:project:bitbucket
- Projects → Admin = admin:project:bitbucket

So just tick Projects → Read.

3. The real blocker — scope ≠ permission. The REST reference says "Only users/clients with admin permission for the project
may access this resource." That's a gate separate from the scope: even with the right scope, the identity behind the token
must be a Project Admin on that project. This is almost certainly your unauthorized error. (Project admin — not workspace
admin.) (REST ref)

Tip: check whether you get 403 (permission gate — not a project admin) vs 401 (credential rejected — bad/expired token).

4. Timely gotcha: if any attempt uses Basic auth with an app password, we're inside the app-password brownout (9 Jun – 27
Jul 2026, removed 28 Jul) — intermittent 401s are expected right now, and API tokens are now the only Basic-auth credential.
(notice)

What works: create an API token for an Atlassian account that is a Project Admin on the target projects, with Projects →
Read, and use Basic auth (email + token). That satisfies both the scope and the project-admin gate. A Project/Workspace
Access Token with the right permission works too as a non-user credential.

In short: it's the project-admin permission gate (or an app-password caught in today's brownout), not a missing scope. Make
the calling identity a Project Admin, use an API token with Projects → Read, and those endpoints will return.

Hope that unblocks you,
Ron

[James_Rodgers]

Thanks for the response. Yes, I am getting a 403 so I do think that having permissions on the project is the issue.
I don't think that gets me there though because there is no way to make an app password anymore. I know they are sunsetting this and, in theory, they still work but I don't see an option to create a new one. 
This line you quote, "Only users/clients with admin permission for the project may access this resource.", would indicate that making an oauth client an admin on a project is possible, any idea how? If that's not possible, this is a big hole in the permissions model.