Does repositories/{workspace}/{repo_slug}/pullrequests/{pull_request_id}/conflicts support ApiToken?

[roustommx]

Hello,

First of all, thank you for your efforts.

I am currently using Bitbucket API Tokens, and I noticed a potential inconsistency with the new conflict detection APIs.

The endpoint:

/repositories/{workspace}/{repo_slug}/pullrequests/{pull_request_id}/conflicts

explicitly states that the following scope is supported:

Forge app and API Token scopes required:

read:pullrequest:bitbucket

However, this endpoint redirects to:

/repositories/{workspace}/{repo_slug}/file-conflicts/{spec}

and the redirected endpoint appears not to support API Token authentication. As a result, I receive the following error:

{ "type": "error", "error": { "message": "This resource does not support authentication using the provided token" } }

For comparison, the standard pull request endpoint:

/repositories/{workspace}/{repo_slug}/pullrequests/{pull_request_id}

works correctly with the same API Token and has the same documented requirement of "Forge app and API Token scopes required".

Could you please investigate whether this is an issue with the implementation or the documentation?

We are currently relying on conflict detection functionality, and we would appreciate clarification as soon as possible, especially given the upcoming deprecation of the merge=true parameter scheduled for September 4, 2026.

Thank you in advance for your assistance. We look forward to your feedback.

[Gabriela - LeanZero]

Hi @roustommx, the spec annotates those two endpoints inconsistently, so one of the annotations has to be wrong.

In api.bitbucket.org/swagger.json, 271 of the 298 operations carry an x-atlassian-auth-types entry naming api-token. GET /repositories/{workspace}/{repo_slug}/file-conflicts/{spec}, the target of your 302, carries no such entry at all. The rendered docs say the same thing quietly. Every operation on the Commits page prints a Forge app and API Token scopes line except that one. The scope moves across the hop too, pullrequest going in and repository at the far end, and you can watch it happen. Call /conflicts without -L and the 302 comes back carrying x-accepted-oauth-scopes: pullrequest.

If merge=true is what you're calling now, that's GET /repositories/{ws}/{repo}/diff/{spec}. It carries api-token, on read:repository:bitbucket. Its classic security block is the one file-conflicts carries, repository in both. So whatever token you already use for diff is the one to aim at file-conflicts, and that costs you a request.

Take the URL off the Location header instead of building the spec yourself. The 302 hands you Bitbucket's own revspec, and it doesn't look like the sha..sha form the docs give for that path parameter. When I ran it against a public repo the Location came back as workspace/repo:sha%0Dsha. Copy it, re-issue it with the other token. Conflicts come back, you're unblocked and the target is missing its annotation. Same sentence again, and no scope is going to move it.

Someone already got that second outcome. github.com/solrevdev/solrevdev.bbx swept the API with a real token on 6 August and logged your exact message against file-conflicts, as a 403, with a note that no scope fixes it. Their repo, and I hold no Bitbucket token to check it against, so treat it as a strong hint and go get your own result.

Nothing is filed in BCLOUD. The only file-conflicts hit there is a 2013 issue about something else. Put both spec entries side by side in the ticket and paste the response verbatim, status line included. You didn't say what code came back with that body. That part carries the weight. A 403 says the credential authenticated and the resource turned its type away, and a 401 would be a different bug report.