Problem

Workspace, Project, and Repository Access Tokens currently require two different authentication modes depending on the operation:

• REST API calls: Bearer authentication (Authorization: Bearer <TOKEN>)

• Git over HTTPS: Basic authentication (x-token-auth:<TOKEN> as username, with a blank or dummy password)

In CI/CD environments like Jenkins, this means teams must create two separate credential entries per token — one for API interactions and one for Git operations, even though it's the same underlying token.

Impact at scale

For organizations managing hundreds of repositories across multiple Bitbucket projects and workspaces, this duplication creates significant operational overhead:

• Double the credential entries to create, maintain, and rotate in Jenkins

• Increased risk of credential drift when one entry is updated but the other is missed

• No API exists for programmatic token management (see https://jira.atlassian.com/browse/BCLOUD-22302), so all credential setup is manual

• Pipeline configuration complexity increases as teams need conditional logic for which credential to use depending on the operation type

Requested solution

Support one of the following (in order of preference):

1. Allow access tokens to authenticate REST API calls using basic auth format (same as Git operations), so a single credential entry works for both

1. Allow Git over HTTPS to accept Bearer authentication with access tokens, so teams can standardize on Bearer

1. Provide any unified authentication mechanism that allows a single credential entry to be used for both REST API and Git operations with access tokens

Related requests

• https://jira.atlassian.com/browse/BCLOUD-23004 — Runners-auto-scaler support for access tokens (related but narrower in scope)

• https://jira.atlassian.com/browse/BCLOUD-22302 — API for access token lifecycle management (compounds this problem since rotation must also be done twice)