Bitbucket webhooks are used by teams every day to test, analyze, deploy, and distribute great software to millions of people.

As Bitbucket webhooks are one of our most popular integration points, we’ve had the opportunity to gather lots of feedback regarding our webhook payloads, usage, and integrations.

We’ve listened to the community (check out public issues #7775, #5938, #4467, #6545 + more) and collaborated with CI vendors to make crucial improvements to this process.

We’re proud to announce the new Bitbucket webhooks.

The new webhooks can be accessed in your repository administration settings as shown in the image above. The webhooks provide a host of improvements over the previous, and soon-to-be deprecated “POST and Pull Request POST” hooks, which have now been renamed to “Services”.

Let’s look at some of the improvements and attributes of the new webhooks.

Fuller, more descriptive payload

Bitbucket webhooks now send more comprehensive information in the payload. For example, a repo:push event now includes detailed payload information about each and every reference that was updated:

Better controls

We’ve added fine-grained control over the events you want to receive hooks for, such as repository, issue, and pull request events:

Improved troubleshooting

You can now troubleshoot malfunctioning webhooks more easily by reviewing the recent requests, including status codes and response times:

Connect-ed

The new Bitbucket webhooks have been written from the ground up as a Connect add-on using our Atlassian Connect for Bitbucket platform, leveraging the same APIs for building powerful add-ons for extending Bitbucket.

Onward!

This is just the beginning. We’ve got more features on the way, such as viewing request details (headers, event payloads, etc.), retrying requests, advanced queuing, and much more.

If you’re currently integrating with the old webhooks (renamed to “Services”), these will be deprecated soon. Please visit our payload documentation for the new payload descriptions.

Take the new Bitbucket webhooks for a spin – you can configure them in your repository settings. Are you inspired to build new, exciting integrations? Clone our webhook-listener demo project to quickly get started with Bitbucket webhooks.

Thank you for your feedback! We’re trying to do a better job on communicating our efforts to the community, but we have to be careful not to over-promise and under-deliver, which caused problems in the past. However, I can guarantee you that all of the top issues are on our radar; expect more frequent updates in the future.

Hi, I am working with Microsoft Azure. We have scenarios where we integrate with Bitbucket. Question about deprecation.
1. existing REST api to set hook will be deprecated (failed) or it adds hook url to the new webhook instead.
2. the already setup services url will be depreated (stop receiving notification) or it will receive the new format instead.

It will be simpler for our migration to have existing hook/api to just work with new format.

How does BitBucket webhook pass a parameter (such as the PR number) via the trigger?
for example, I would like to create a webhook to trigger a jenkins job but I would like the Jenkins job to know from which PR this trigger was coming from.

It’s been almost a year at this point. Are there any plans to extend this to Bitbucket Server? It seems really strange that the _enterprise_ product doesn’t have this ability, since it’s _so_ important to build custom integrations.