### Release notes When triggering a pipeline using a webhook the payload is lost in the way, in some cases the payload carries important information that can determine how the triggered pipeline should work. in this release, we've added a new predefined variable to capture the webhook body so it can be kept and be used in the triggered pipeline. ### Problem to solve At the moment you can trigger a pipeline in a different project or the same project [based on webhooks](https://docs.gitlab.com/ee/ci/triggers/#triggering-a-pipeline-from-a-webhook). The only problem is that the body that get's posted on the trigger gets lost in the process and can't be retrieved from the CI job that get's triggered. ### Intended users Developer ### Further details A use-case for us would be: On each project we could add a webhook on the [merge request events](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#merge-request-events). Within the **Settings --> Integration** we could add a URL to a different GitLab project, for example **https://gitlab.example.com/api/v4/projects/9/ref/master/trigger/pipeline?token=TOKEN**. The trigger job on that project should have the body of the webhook passed into it. So within that job we could analyze the body from the webhook and based on some values to or maintaince tasks or other nice things. ### Proposal Pass the webhook body to the triggered job. as a file type variable ### What does success look like, and how can we measure that? The webhook body should be passed to the trigger job ### Links / references <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->