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_ · Accepted solution]

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.

[Arkadiusz Wroblewski]

Hello @Chatree Kunjai 

The issue is the authentication scheme.

You mixing up Token type and auth Method.

The confusing part is that Atlassian’s REST examples often show Authorization: Bearer <access_token> on those endpoints. That is valid for OAuth/access-token flows, but not for the user API token shown in your screenshot. Atlassian also documents that repository, project, and workspace access tokens are a different token family, tied to that repo/project/workspace rather than to your user account.

Access tokens | Bitbucket Cloud | Atlassian Support

For the token shown in your screenshot, use Basic auth, not Bearer.
If you specifically want Bearer, then use OAuth or a Bitbucket access token, not a user API token.

One nuance though: for GET /2.0/user, Bitbucket’s REST reference lists the API token scope as read:user:bitbucket. In your post you mentioned read:account (Classic), so if /user still fails after switching to Basic auth, I would double-check the scopes on the token and recreate it with the exact read:user:bitbucket permission if needed.

The Bitbucket Cloud REST API