Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

REST API: how to check if a PR has conflict(s)

As far as I know, the /pullrequests API ( doesn't offer a way of checking if a PR has conflicts.

I'm aware of the state attribute (MERGED, SUPERSEDED, DECLINED), but it won't help here, because all it shows is the status of the PR after an action has been taken.

I've also checked the pullrequests/{pull_request_id}/statuses endpoint, which also returns a state attribute, but again it only makes sense after some other thing has happened (a Pipelines build, for example):

Ideally, as soon as a PR has been opened (independently of Pipelines or any further human interaction), some API endpoint should allow me to check if that PR contains conflicts or not.

Does anybody know of an indirect way of doing this? Preferably through an endpoint that does exist ;)


4 answers

One solution is to get a diff of the PR from the api and grep it for for instances of "<<<<<<<"  That will indicate if there is a conflict.

That worked for me! Thank you!

In Bitbucket Server:





Great!  Thanks - Just a note for anyone coming across this later - GET from this URL if you just want to check the status.  A POST request to this endpoint will actually try to perform the merge, which may not be what you want.



So was in the same pinch, checked source code of the pull request html page and found out that there is indeed an endpoint for checking conflicts. 

And that is *Drumroll please*<org_or_profile>/<repo_name>/pullrequests/<pull_request_id>/conflict-status

For example I got the pull request id from:<org_or_profile>/<repo_name>/pullrequests/?

Then used that ID in the above conflict-check endpoint. 


Deleted user Oct 19, 2018

1.0 api will be deprecated at the end of the year. Is there a way to get the conflict-status on 2.0?

Like # people like this

My paid add-on, Bit-Booster - Rebase Squash Amend, makes that info available through its own internal API (servlet/bb_rb).

e.g., if you install my add-on, then this endpoint becomes available:


Look for the "isConflicted" key in the API response.

You can see the API whines about the add-on license being expired, but it never stops working.


{"enabled" : true,
"warn" : "Bit-Booster <a class='bbErr' target='_blank' href='http://localhost:7990/bitbucket/plugins/servlet/upm#manage/'>license expired</a>. 10 free rebases remain for today.",
"userHasWrite" : true,
"commitCount" : "1 commit",
"fromBranch" : "m",
"toBranch" : "basic_branching",
"tipMsg" : "b",
"isSquashed" : true,
"isRebased" : false,
"isConflicted" : false,
"blockMsg" : "",
"authors" : ["Administrator &lt;;","Sylvie Davies &lt;;"],
"defaultAuthor" : "Sylvie Davies &lt;;",
"amendAuthor" : "Sylvie Davies &lt;;",
"squashMsg" : "b",


But if you disable the Rebase, Squash, Amend functionality through Bit-Booster's config screen, then the API just returns this:


{"enabled" : false,
"warn" : "Bit-Booster <a class='bbErr' target='_blank' href='http://localhost:7990/bitbucket/plugins/servlet/upm#manage/'>license expired</a>. 10 free rebases remain for today.",


Looks like it covers what we need. Does that addon work for Bitbucket Cloud as well?

Oh, sorry, Bitbucket Server (on-prem) only.   To implement this for cloud we'd need to store git repos for every customer, which is something we're not interested in doing at this time.

Here's the code (Java, using the JGit library) we use to calculate if the merge has a conflict or not:

ThreeWayMerger merger = MergeStrategy.RECURSIVE.newMerger(fileRepo, true);
ObjectId b1 = ObjectId.fromString(branch1);
ObjectId b2 = ObjectId.fromString(branch2);
boolean canMerge = merger.merge(b1, b2);

You might be able to suit that to your needs.  Note: that code creates a new tree-object in the git object database (the result of the merge), but since we never bother creating any pointers to the tree-object, subsequent "git gc" invocations clear it out.

Thanks for your help, @Julius Davies _bit-booster_com_ (and for sharing your code)

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events