There is a webhooks API. See this reference.

The webhook API documentation at https://developer.atlassian.com/static/rest/bitbucket-server/5.5.0/bitbucket-rest.html#idm140236731154672 is lacking details though about the request body JSON format to create a new hook.

The documentation includes an example JSON response after successfully creating a webhook. I tried sending the same kind of JSON object in the request and that created a webhook OK. Bitbucket Server apparently ignores the "id", "createdDate", and "updatedDate" properties of the request JSON object.

In Jenkins, I can open the configuration page of a job, add the "Override hook management" behavior to a "Bitbucket" branch source, and change the setting to "Disable hook management". I hope this setting will work with Bitbucket Server too, so that I can configure the webhook manually and not have to grant REPO_ADMIN permission to Jenkins. However, it is not clear how I would then tell Jenkins the webhook secret with which Bitbucket Server will authenticate the payload. Or is Jenkins going to validate the HMAC at all?

I created a branch with some changes at https://github.com/jenkinsci/bitbucket-branch-source-plugin/compare/master...kwin:bbserver-use-native-webhooks This is not complete yet as I still have to figure how to correctly fill the changes in BitbucketServerPushEvent and BitbucketServerPullRequest.

eernie Maybe you can have a look from there, as you did the original implementation against your own plugin.

At first glance: LGTM. 

Building it like this will mean that the plugin is no longer supported ( Fine by me), have you thought about maybe supporting both first? Or maybe first deprecating the current version in favor of the new version? Either way is fine by me, as we can update Bitbucket to 5.5.0 very easy. I'll attach a diagram of current installed on which version.  Do note that the plugin isn't used for Jenkins only, but the majority does.

I would love to see this implemented. Having backwards compatibility or even just multiple method signatures that allows using the old behavior when an extra field like BitbucketType isn't present, would be sweet. The new smart parsing fuctionality looks fantastic and I really hate having to purchase a plugin on the Bitbucket side to send "dumbed down" webhooks to Jenkins if the existing Jenkins built in could handle the newer BB 5.4.x and higher payloads itself.