How to Retrieve Repository Permissions for Non-Admin Users After /user/permissions/repositories Depr

[Rajashekar G]

Hello Bitbucket Support Team,

We are currently migrating away from the deprecated API:

GET /2.0/user/permissions/repositories

This endpoint was previously used to retrieve the list of repositories that the authenticated user has access to, along with the user’s effective permission (admin/write/read), across all workspaces.

As per the documentation, the recommended replacement is the workspace-scoped API:

GET /2.0/workspaces/{workspace}/permissions/repositories

However, we have observed the following behaviour

• The new workspace-scoped permissions API can only be accessed by users who have admin permission on the workspace.

• When the authenticated user has only write or read permission on a workspace, the API returns an access error and does not allow retrieving repository permissions.

• This makes it difficult to replicate the behaviour of the deprecated endpoint, which worked for all permission levels and returned only the repositories the current user had access to.
  
  What is the recommended approach to retrieve the current user’s repository permissions (admin/write/read) across workspaces when the user is not a workspace admin?

[Syahrul]

Hey @Rajashekar G 

Welcome to the community, and thanks for the detailed explanation.

You’re correct in your observations:

• GET /2.0/user/permissions/repositories is deprecated.

• The documented replacement, GET /2.0/workspaces/{workspace}/permissions/repositories, can only be used by workspace administrators, so it’s not a one-to-one replacement for non-admin users.

• This workspace-scoped endpoint is intended for admins to review and manage permissions across repositories and users in a workspace.

• There is no longer a single cross-workspace endpoint for non-admins that replicates the old behaviour in one call; the supported approach is now a multi-step pattern (list user workspaces → list repositories per workspace → aggregate client-side).

I hope this clarifies the current behaviour.

Regards,
Syahrul

[Rajashekar G]

Hi @Syahrul 

Thanks for the clarification, that matches what we’re seeing.

When GET /2.0/user/permissions/repositories was deprecated, the changelog indicated there would be a replacement (CHANGE-2770: https://developer.atlassian.com/changelog/#CHANGE-2770
). A follow-up changelog later introduced the new endpoint (CHANGE-3022: https://developer.atlassian.com/changelog/#CHANGE-3022
).

However, GET /2.0/workspaces/{workspace}/permissions/repositories is not a practical replacement for our use case:

It is admin-only, whereas the deprecated endpoint worked for all users.

It requires a multi-step approach (list user workspaces - list repositories per workspace - aggregate client-side), resulting in multiple API calls per workspace for data that was previously available in a single request.

The admin-only endpoint doesn’t work for us, as all users need to be able to retrieve their own repository list and permission levels.

At the moment, there doesn’t appear to be a true replacement for non-admin users. It would be helpful to know whether a user-scoped alternative is planned, or if this increased call complexity is now the expected behaviour.

[Syahrul]

Hey @Rajashekar G 

At the moment, I don’t have any insight into whether there are plans for a similar API endpoint or an alternative scope.

However, I’d be happy to raise a feature request on your behalf. Could you please share your use case and how you intend to use this functionality?

Thanks!
Syahrul

[Raj]

@Syahrul 

We’d appreciate you raising a feature request.

Our use case requires a user-scoped API (non-admin) that allows an authenticated user to retrieve all repositories they have access to, along with their permission level (e.g., read/write/admin), with support for pagination, as users may have access to a large number of repositories.

Previously, GET /2.0/user/permissions/repositories fulfilled this need in a single, paginated call for all users. The current replacement endpoint (/workspaces/{workspace}/permissions/repositories) is admin-only and heavily workspace-scoped, which introduces significant complexity and does not work for our scenario.