What's the problem this feature will solve?

In some cases, RTD users are not able to create a custom webhook payload for RTD because it's coming from a source they don't directly control. This payload may contain all the right fields but in unexpected locations in the JSON.

This feature would allow users using third party webhook issuers (e.g. on-prem Bitbucket, which issues a different payload structure than Cloud Bitbucket) to successfully trigger builds without having to adhere to the specific POST content structure required for incoming RTD webhooks.

Describe the solution you'd like

I would like a way to map incoming payload items to the three fields currently allowed in incoming webhooks. For example, the branch name in a Bitbucket webhook coming from a PR is $.pr.fromRef.displayId, which I would like to map into the required branches parameter.

Alternative solutions

My current workaround is to send the webhook from Bitbucket to Jenkins, which supports JsonPath extraction of variables. I then send a curl request to RTD from my Jenkins server. This means every project must have an additional, customized job just for passing this webhook through, in addition to storing the additional credentials for RTD (API token).

Additional context

I think a JsonPath would be the way to do this. In the Generic Webhook form, there would be an additional (optional) field to specify the location in the incoming payload where the value for branches, default_branch, and token are sent.