HTTP Access Token returns 401 "not supported for this endpoint" on all REST API v2 endpoints

Chatree Kunjai

Hi, I'm having trouble using an HTTP Access Token with Bitbucket REST API v2.

I created a Personal Access Token with these scopes:

- read:account (Classic)
- read:repository:bitbucket / write:repository:bitbucket
- read:pullrequest:bitbucket / write:pullrequest:bitbucket

The token shows as active on the API Tokens page (expires Apr 2027, last accessed ~15 mins ago), but every curl I try returns the same error:

401: "Token is invalid, expired, or not supported for this endpoint."

Both of these fail:

curl -H "Authorization: Bearer <token>" https://api.bitbucket.org/2.0/user
curl -H "Authorization: Bearer <token>" "https://api.bitbucket.org/2.0/repositories?role=member&pagelen=1"

The weird part is — Basic Auth with App Password works perfectly on the same endpoints.

Has anyone run into this? Is there something different about how Bearer tokens work compared to App Passwords?

Is there a known issue with HTTP Access Tokens on Bitbucket Cloud REST API v2?

Or is there something specific about how Bearer tokens need to be formatted/used?

Ajay _view26_

Hi @Chatree Kunjai 

I think the key issue is the auth method, not the scopes.

Bitbucket’s current docs distinguish between:
- API tokens, which authenticate with Basic auth using your Atlassian email as the username and the token as the password
- OAuth/access tokens, which use `Authorization: Bearer ...`

So if the token you created came from the Bitbucket API Tokens page, using it as a Bearer token on `/2.0/user` and `/2.0/repositories` would explain the “not supported for this endpoint” response.

I would try:
- Basic auth with your Atlassian email + that API token
- not `Authorization: Bearer ...`

So for example, the likely fix is to stop treating that token like OAuth and instead use it as a Basic-auth password. That would also explain why App Password basic auth works on the same endpoints.