Skip to main content
We highly recommend using either our notify-qawolf-on-deploy-action if you use GitHub Actions or our JavaScript SDK attemptNotifySuccess function directly. See @qawolf/ci-sdk

​
Post to /api/webhooks/deploy_success Webhook

HTTP Method: POST

​
Sample Query

Shell
curl -X POST -H "Authorization: Bearer <ApiKey>" \
     -H "Content-Type: application/json" \
     "https://app.qawolf.com/api/webhooks/deploy_success" \
	     -d '{"branch": "<BranchName>", "deployment_type": "staging", "commit_url": "<URL>", "sha": "de12adda500f2bc5a29dbd89f4fb1b0e1a31de81"}'
This command is for illustration purposes. We don’t recommend “curling” without inspecting the result as not all 200 responses imply a successful run trigger. We recommend using the SDK for that purpose as it does the interpretation work for you!
Go to https://app.qawolf.com/<team slug>/settings/integrationsOr, navigate via the UI:

​
Required Request Headers

Header NameHeader ValueDescription
AuthorizationBearer api_***Provide a string constructed by appending your team API Key to Bearer.
Content-Typeapplication/json

​
JSON-formatted Request Body

This POST request supports a JSON-formatted object with the below fields. All fields are optional.

​
Commonly Used Fields

FieldValueDescription
branchGit branch nameIf a Git commit triggered this request, send us the relevant branch name so that we can display it in the UI and find any pull requests on the GitHub repo linked to any triggers that match.
deployment_typeArbitrary string setup in triggers.This field must be provided if the target trigger requires matching a deployment type.
deployment_urlURLIf you send this, it will be available in your tests as process.env.URL for any runs created by this deployment notification.
shaCommit shaIf a Git commit triggered this request, send us the commit SHA so that we can create GitHub commit checks if you have a GitHub repo linked to any triggers that match. We also use this to display a link to the commit in the run UI.

​
Advanced Fields

FieldValueDescription
variablesDictionary of key/valuesA dictionary of environment variable names/values that will override any variables from the associated environment in every run that your notification triggers.
commit_urlURLIf your deployment triggers do not specify a hosting service repo, pass this URL along with sha to ensure that the commit ID will be a clickable link everywhere in the QA Wolf UI and notifications.
deduplication_keyArbitrary stringBy default, any new run will cancel ongoing runs which have the same branch (see field above) / environment (determined by the trigger) combination. If only environment is available, cancelation will occur for runs in the same environment. You can customize this behavior by providing a custom key. All new runs that start as a result of this notification will auto-cancel all previous runs with the same key that are not yet finished.
hosting_serviceGitHub | GitLabBy default, we use GitHub, but pass GitLab for GitLab integration support.
ephemeral_environmentBooleanIf your deployment is not associated with a code-hosting integration. Pass this field along with deployment_url
Passing commit_url will display a link to the commit at the top right of the run page, and anywhere else the commit ID appears.

​
Choosing Fields Based on Your Setup

Please note that these are meant to be triggered by your main environment, per the contract with QA Wolf. If you need additional environment support, please reach out to our team. There are both technical and account implications for secondary environments that are not fully covered in this document.
Use deployment_url to point to the appropriate deployment (especially if it is dynamic for the setup environment associated with the trigger).
deployment_type may be required if it was configured in your trigger

​
With GitHub/GitLab app installed

See Install GitHub/GitLab App for more guidance.
Provide the sha, branch, hosting_service.

​
Using custom CI pipeline (or not using GitHub/GitLab App)

Provide commit_url, branch, ephemeral_environment.

​
Response

​
200 Responses

The response will look like this: 
{
  "results": [{
    "created_suite_id":"cl1f6i0in15676w115vt43vw2",
    "trigger_id":"ckzoog9wy01720xyrvl8ah7gu"
  }]
}
results is an array of all the matched triggers including either created_suite_id if suite (aka run) was created, or failure_reason if it could not be created, or duplicate_suite_id if suite (aka run) was previously created and a skip_reason explaining why. In case the request was made with a previously used sha, and a suite was already created for that deployment, the response will look like:
TypeScript
{
  "results": [{
    "duplicate_suite_id":"cl1f6i0in15676w115vt43vw2",
    "skip_reason":"Suite already created"
    "trigger_id":"ckzoog9wy01720xyrvl8ah7gu"
  }]
}
In this scenario we get a duplicate_suite_id in place of a created_suite_id signifying that a new suite wasn’t kicked off, and one for this deployment already exists.
The endpoint can return 200 while no run was ever created. You should inspect the response to determine the success status, or use our SDK attemptNotifySuccess function which will do that for you.

​
HTTP Status Error Codes

CodeDescription
401Missing or invalid credentials. Make sure you are using the Authorization: Bearer XXX with XXX the API token for your team.
403Forbidden. Usually indicates a disabled team. Contact support.
404Run not found.
405Method not allowed. Make sure you use POST.
500Internal server error. If the issue persists, contact support.

​
Failure Codes

​
multiple-runs-with-same-deduplication-key

This error happens when there is a deduplication_key set in the request and there are multiple matching triggers (multiple runs would start) making them cancel each other based on our superseding mechanism. If you meant to initiate multiple runs for this deployment, do not provide a deduplication_key. If you did NOT intend to initiate multiple runs, please contact your QA Wolf representative, this might be a configuration issue.
Last modified on February 9, 2026