OAuth client_credentials returns 404 for a private repository in another workspace

[Júlio Lemos]

We have a GoCD integration with the Bitbucket Cloud API using OAuth 2.0 and the
client_credentials flow. Its last successful execution was on August 13, 2026.
The token is still issued successfully and includes the repository,
repository:write, pullrequest, and pullrequest:write scopes, but requests to a
private repository now return HTTP 404.

The OAuth client belongs to an old personal workspace, while the private
repository belongs to another workspace in the organization. The account that
owns the personal workspace has access to the private repository.

We also reviewed the permissions configured for the OAuth client and confirmed
that they are correct. The required scopes remain enabled, and the owning
account's access to the repository was also confirmed.

GET /2.0/user identifies the token as an app_user rather than as the account
that owns the OAuth client.

We performed the following tests:

- token generation through client_credentials succeeds;
- a public repository in the target workspace returns HTTP 200 with or without
the token;
- the private repository returns HTTP 404 with or without the token;
- the service account can access the private repository through Git/SSH;
- we created a second OAuth client in the same personal workspace and observed
the same behavior.

This indicates that the OAuth clients' app_users are not receiving the access
that the owning account has in the other workspace.

Has there been a recent change to OAuth client_credentials, app_user behavior,
or cross-workspace access that would explain this scenario?

Why is the existing access no longer recognized by the app_user even though
OAuth 2.0 continues to issue valid tokens with the same scopes? Is there a
Bitbucket permission or association that needs to be restored so the current
OAuth client can access private repositories in the other workspace again while
keeping the client_credentials flow already used by the integration?

Has anyone experienced this issue before? Thank you in advance for any help.

[Viswanathan Ramachandran]

Hi @Júlio Lemos 

The issue is caused by Bitbucket's OAuth 2.0 Client Credentials architecture. When using client_credentials, bitbucket acts as a bot principal (app_user) tied strictly to the workspace that owns the OAuth consumer and not the personal account that created it.

Even if your user account has access to the target workspace, the app_user generated in your personal workspace does not inherit your personal permissions. Bitbucket returns an HTTP 404 (instead of 403) for private repos in other workspaces to avoid exposing their existence to unauthorised identities.

To resolve this, use one of the following options:

• Option 1 (Recommended): Re-create the OAuth Consumer in the Target Workspace - Workspace Settings > OAuth consumers, create a new client there, and update your GoCD credentials. Since the consumer will be owned by the target workspace, its app_user will have access to those private repos.
• Option 2: Switch to Workspace Access Tokens Go to the Workspace Settings > Security > Access Tokens and generate a Workspace Access Token with the required repository and pull request scopes. Use this token directly in GoCD.

[Júlio Lemos]

Hi @Viswanathan Ramachandran 

Based on your clarification, we’ll coordinate with the responsible team to recreate the OAuth 2.0 consumer in the workspace that owns the repository and update the GoCD credentials.

After testing the new configuration, we’ll share the results here.

Thank you for your guidance.

[Arkadiusz Wroblewski]

Hello @Júlio Lemos 

That you have more clarity, that's related to this change

OAuth change announcement:

https://community.developer.atlassian.com/t/oauth-2-0-and-api-authentication-changes-for-bitbucket-cloud/99003 

Actual documentation also pointing that 

OAuth setup documentation:

https://support.atlassian.com/bitbucket-cloud/docs/use-oauth-on-bitbucket-cloud/ 

That should help you mainly understand that.

Best,

Arek 🤠 

[Júlio Lemos]

Hello @Arkadiusz Wroblewski,

This confirms the cause of the issue and clarifies the changes required on our side.

Thank you for sharing the official references.

Best regards!