Outgoing webhooks in continuous integration jobs

How to add outgoing webhooks to CI jobs to trigger third party services

Catherine Bacon avatar
Written by Catherine Bacon
Updated over a week ago

Continuous integration within Gearset is a powerful tool, but what if you need to trigger third-party services as part of your release process? 

Outgoing webhooks allow you to automate this process, so you can kick off Selenium tests (for example) if your CI job runs successfully.

Any service with an API can be triggered directly from within Gearset.

Setting up a CI job with outgoing webhooks

To create a CI job with outgoing webhooks, start by following the usual setup process.  On the Outgoing webhooks tab you can add the URL you’d like Gearset to POST to, and select which events you would like the webhook to trigger on.

When the CI job finishes, we'll send a POST request with your chosen payload to the outgoing webhook URL.

Multiple outgoing webhooks are supported, so you can simultaneously trigger various services to create more customized flows. You can add descriptions to keep track of each outgoing webhook.


Gearset's standard payload includes information about the CI job and run. This article has more information about the standard payload.

With a custom payload, you can choose:

  • whether to include a Basic Authentication or an Authorization HTTP request header

  • the payload format, either application/json or application/xml

  • the payload body

Custom payloads don't add any information about the CI job or run, so you'll need to add any details to your payload.


You can use template variables to include details about the CI job and run to your custom payload. These variables are filled when Gearset sends the POST request.

Variables are referenced using the {{VARIABLE_NAME}} syntax. The following variables are available:

Variable name



Gearset's CI job ID


Gearset's CI job name


Gearset's CI job type


Gearset's CI job run deployment package ID


Gearset's CI job run ID


A boolean indicating whether the job run was successful or not


A message containing a summary of the CI job run, including the type of job, it's source and target and whether it was successful or not


A url to check the job run details in Gearset


The name of who triggered the CI job run in Gearset


The source for Gearset's CI job


The type of the source for Gearset's CI job (e.g. Git branch, Production Salesforce org)


The target for Gearset's CI job


The type of the target for Gearset's CI job (e.g. Git branch, Production Salesforce org)


When the source of the CI job is a Git branch, this contains the Git commit hash that was used as the source of the CI run.


When the source of the CI job is a Git branch, this contains the email of the commit author.


When the source of the CI job is a Git branch, this contains the name of the commit author.


When the source of the CI job is a Git branch, this contains a url to check the commit in your version control system.

This example shows an outgoing webhook that uses a custom payload with the SOURCE_COMMIT_ID variable. When the CI job finishes and triggers the webhook, the variable is replaced with the source branch's commit hash.

Common Integrations

Many customers look to integrate Outgoing Webhooks from Gearset with a selection of common 3rd party tools. Here are some useful resources to help you set up your integrations with these platforms.


Gearset offers out of the box integration with Slack notifications. Our default integration, containing dynamic information about your CI jobs, can be configured on the Notification settings tab, after running through this guide.

However, customized static content can also be sent to Slack by configuring an outgoing webhook. You'll need to begin by creating an Incoming webhook URL from Slack, and then adding whatever content you would like as a JSON formatted payload. The Slack webhook URL already contains an authentication secret, so no additional authentication needs to be provided.

Azure DevOps

To trigger events in Azure DevOps, you will need to use their public REST API. Once you have found the appropriate POST endpoint, add that to the URL field. You will then need to generate a custom JSON payload based on the chosen endpoint's documentation.

Customers often want to queue a build in Azure DevOps once a CI job has succeeded - this REST API endpoint is documented here.

Azure DevOps' REST API requires authentication - you will need to create a Personal Access Token (PAT) with appropriate permissions. Then, Base64 encode your username and PAT following the instruction here. Select Authorization as the authentication type for the outgoing webhook, and add the Base64 encoded string to the credentials field.

Provar Testing

You can execute tests in Provar at the end of a CI run by setting up an integration with Provar Manager, or by triggering a custom Jenkins CI server job.

Tricentis Test Automation for Salesforce

You can execute tests in Tricentis Test Automation for Salesforce at the end of a CI run using their public REST API.

Is a guide for your integration missing? Let us know!

Did this answer your question?