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?

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