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.

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:

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:

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.

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.

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.
​

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.

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!