2da1b854664c 's idea to simply add an extra "fullHash" parameter to the payload makes a lot of sense, should be pretty easy to implement, and would be very helpful for our specific usecase (we currently maintain a few Bitbucket Cloud apps).

I'd like to argue a case for bumping up the priority of this issue since it basically makes integrations with Bitbucket quite extra painful.

We at DeepSource have a powerful [integration|https://marketplace.atlassian.com/apps/1222731) with Bitbucket. For every `PR:updated` webhook event, we are required to make 2-3 requests to the Bitbucket API to fetch the full commit hashes against the destination commit hash, source commit hash, and also the merge commit hash if it is a `PR:fulfilled` event. For our large customers on Bitbucket cloud, this results in us exhausting the API rate limit (which is 1000/hr for `/repositories` resource) quite often which renders our integration useless for them which is in no way ideal.

We could add larger SHAs but this will be a backwards incompatible change (i.e. some people maybe assuming the smaller SHAs). bq.

That is a valid concern. But why not just add a new field (e.g.`fullHash`) to not break backward compatibility but also solving this pain point for newer as well as existing integrations?

I agree that this isn't ideal, however, with any API change we run the risk of breaking any client or application that was dependent on only the short version of the hash. Any solution will need to take this into account.

The work around for now would be to make a request to the commits API which will provide the full hash. Fore example if you go to https://api.bitbucket.org/2.0/repositories/bitbucket/django-piston/commits/260113c43ff8 you can see we use the short hash in the URL but the response includes the full hash.

So the body of the webhook is based on the body of the REST API response. The API response only contains abbreviated commit hashes. We could add larger SHAs but this will be a backwards incompatible change (i.e. some people maybe assuming the smaller SHAs). It's unlikely this will be fixed in the short term.

There is a URL in the response that can be used to get the full hash if you really need it. So in the destination field you get something like:

{
  "destination": {
    "commit": {
      "type": "commit",
      "hash": "c6cf4f931bb8",
      "links": {
        "self": {
          "href": "https://api.bitbucket.org/2.0/repositories/xxx/xxx/commit/c6cf4f931bb8"
        },
        "html": {
          "href": "https://bitbucket.org/xxx/xxx/commits/c6cf4f931bb8"
        }
      }
    }
  }
} 

You can then hit the destination.commit.links.self.href URL and get a response like with a ?fields=hash query parameter to get something like:

{"hash":"c6cf4f931bb885590d461236448ec8a9ef43f4f2"}

There will be similar links for any other PR hash that you want to lookup.