pullrequest listing API is necessary. (BB-2021) (BB-7094)

Issue #3442 resolved
Hyunsik Choi
created an issue

In current REST API, we can get only brief pull request information (without title, message, and revision) through the events API as the below: http://confluence.atlassian.com/display/BITBUCKET/Events

However, it is very useful to users if an API to list recent pull request events with more description is supported. Then, the bitbucket would be widely used with various applications. It will enable the pull request to be one status of jira workflow.

Comments (40)

  1. Guido Scalise

    This is a must for us. We have a project that sits in several repositories, and monitoring pullrequests is a PITA.

    Allowing us to list pull requests on a per-repository basis (maybe even on a per-branch basis) with the REST API would be great.

  2. Daniel Bryant

    +1 To this. Github have an awesome API that I'm using, but I really want to move to BitBucket.

    I'm actually surprised this feature is missing from the current API, as getting a list of outstanding pull-requests seems like a no-brainer in the world of social coding?

  3. niclashoyer

    Very sad that there is no pull request api yet. This currently prevents us from moving to BitBucket, as the main communication happens in pull requests. If we can't get our CI to read the open pull requests, it is useless.

    EDIT: as a (very ugly) workaround we now use


    and parse the html content, as there is no other way to get a list of pull request ids.

  4. Erik van Zijst

    We did write an API for this, but due to shifting priorities we've had no time to finish it and as a result we have not been able to officially release it.

    However, it does exist and is accessible to everyone:


    I must be clear that this a work in progress and things may change incompatibly without notice!

  5. Anonymous

    Is there a way to get all the files added/associated with a pull request? With v1.0, the API returns only the files associated with at least a comment. It ignores the files which have no comments against them. With v2.0, I do not see a way to get all the files too.

  6. Daniel Bryant

    @Schneider-Electric This may not be the answer you are looking for, but you can get the patch for each pull request as follows


    In the content returned by this URI any line that begins with 'diff' will end in the name of the file changed as part of the pull request patch. e.g. we can see that rpython/jit/tool/test/test_traceviewer.py has been modified

    diff -r 388909aea9514189bb4d9f9d3bc146891ec0c4b1 -r f7dffcd98d3fa6b6a184342a9670ac7cf85ade36 rpython/jit/tool/test/test_traceviewer.py

    With a bit of regex/grep magic (and some spare time!) this could work for you unless a better solution is forthcoming?

  7. Erik van Zijst

    @danielbryant_uk @Padmanava Debnath Indeed, that's what I'd do.

    I did briefly discuss this issue internally to see if this issue warrants a change to the API (e.g. an extra href to something like /pullrequests/150/files that would give a json list of filenames), or whether we want to keep the API free of this kind of redundancy and expect users to look at the patch.

  8. Daniel Bryant

    @Erik van Zijst Could I vote for the extra /pullrequests/150/files href in the API please (assuming that it is open for a vote :) )?

    Being able to get a list of files changed within a pullrequest would be really useful for the Adopt OpenJDK project I'm involved in, as we need to determine which sponsors/mentors to notify depending on which part of the JDK has been modified in any given pullrequest.

  9. Anonymous

    Thanks Erik, Daniel,

    I did check the /patch URI earlier today. That looks like a 'patchy' way to get the files, but for now, seems to be the only option. I liked the /diff URI which had a nice/intuitive JSON format with the files. Unfortunately, it got removed earlier today.

    I would definitely vote for a /files URI, or something neat to get the files.

  10. Erik van Zijst

    @danielbryant_uk For sure! Just raise a separate issue for it so we can actually keep track of it.

    To be honest, I have no plans for it at the moment. Just adding it like that would require people to make 2 requests. Embedding it in the pull request request would fix that, but make the API significantly more expensive (especially when listing a whole bunch of PRs).

    Lastly I'm afraid that the next request might be diffstat info, which might lead to yet another href and another request for users to make.

    Any suggestions?

  11. Daniel Bryant

    @Erik van Zijst Yeah, that's a fair point, and in my experience it always a tricky balance between keeping everybody happy vs a functional API

    I'm a big fan of following advice by the Apigee crew when designing APIs, and I'm wondering if a partial response option could be viable here? (more details: https://blog.apigee.com/detail/restful_api_design_can_your_api_give_developers_just_the_information)

    Or maybe an 'additional response' parameter that clients would have to specifically set, which could request files included? e.g.


    I've got to disappear now, but I'll open a ticket on this topic tomorrow...

  12. Steven Peters

    @danielbryant_uk thanks for the tip. Seeing the link in this pull request was my first clue that there was something new that was available. We'll start tinkering.

  13. Erik van Zijst

    @Padmanava Debnath Regarding this morning's removal of the JSON /diff property, that should never have been in the API, but accidentally ended up there as a side effect of the work that was done for online editing recently (which relies on json-based diff info). This should have been placed under an internal API endpoint, but accidentally made its way into the public PR api.

    This morning's removal of it therefor fixes that "regression" (prior to the release of the online editor, pullrequests/150/diff actually returned a plain text patch, as it does now).

    I'm not opposed to a json formatted diff, but its layout should not be driven by the requirements of a specific feature that we're building at that time. It should probably also be under something like /patch/master?format=json, or /patch/master.json instead of occupying an independent URL path. Anyway, at the moment there are no plans for that.

  14. Erik van Zijst

    @danielbryant_uk Yes, client-driven field expansion would be ideal. We've been experimenting with that for several years in our other products, but hasn't made it to Bitbucket as of yet.

    The good news is that our new API's backend does support it internally, so we might add support for it later on. If/when we do, then I agree that we can be more generous with in-lining expensive fields on objects.

  15. Erik van Zijst

    Is there any documentation for 2.0 version of the API?

    Not yet. Or actually, we do, but we don't want to publish it until we finish the API (we haven't done POST/PUT/DELETE yet). Anyway, like @danielbryant_uk said, these 2.0 APIs should be pretty self-describing and require little documentation (or we're doing something wrong 😉).

  16. Erik van Zijst

    I like that script! We have indeed made a couple of changes over the past weeks, but the good news is that you should expect the official release next week. After that it will also cease to change any further.

    There's one more change you'll need to make in your script though. We're removing the /patch link from pull requests and instead you should be using /diff.

  17. Daniel Bryant

    Very much looking forward to the release Erik! Will the #7630 [files resource for pull request] be included (or similar functionality)?

    The open source project I'm working on depends on getting a list of the files changed in each pull request (and you'll have our eternal gratitude :-))

  18. Nathan Goldbaum

    Yes, we've also been using the API for quite a while now and are looking forward to the release. A Jenkins instance doing CI tests using the PR API provides a functional replacement for travis on github.

  19. Log in to comment