Test after a deployment

Use this workflow to check your application's critical journeys after a deployment succeeds. Your pipeline calls a Test Plan's webhook; HiTest executes the plan in the background and your team reviews the saved result.

Before you begin

A Test Plan with Active test cases and steps.
A successful manual run of the coverage you intend to automate.
Test Accounts and data that work in the deployed environment.
Access to your CI system's secret storage and available workspace credits.

DeployWait for the application deployment to succeed.
TriggerPOST to the plan's secret webhook URL.
ExecuteHiTest prepares and runs the selected cases.
ReviewOpen Runs or follow a result notification.

A 202 Accepted response confirms dispatch. The saved Run provides the test result after execution.

1. Enable the plan's webhook

Open Test plans, edit your plan, and turn on Webhook under Automatic runs. Copy the generated Webhook URL, save the plan, and make sure the plan is Active.

Store the complete URL as a CI secret. It authorizes execution of that plan; keep it out of source files and public logs.

2. Connect the deployment pipeline

Choose the guide for your CI system and add the request after the deployment's success step:

GitHub Actions

Store the webhook URL in an Actions secret and call it after deployment.

GitLab CI

Pass the secret URL through a CI variable and trigger the plan from your pipeline.

For other systems, use the cURL example. Send a required message that identifies the deployment. For a preview environment, add overrideBaseUrl to use that URL for this execution.

{
  "message": "Preview deployment ready for regression checks",
  "overrideBaseUrl": "https://preview.example.com"
}

The override changes the starting URL for this execution. Test Accounts and case configuration still come from the project, so they must work in the preview environment. See Deployment webhooks for the full payload and responses.

3. Route results to your team

On Notifications, create an Active rule with Run started / Run completed and an Email or Slack destination. The completed event includes Passed and Failed results. See Notification integrations for destination setup.

4. Verify the integration

After the next deployment triggers the request, check the response, then open Runs in the project. Confirm that a new run appears, the intended cases execute, and the completion notification reaches the configured destination.

Acceptance is not a passing result

The webhook returns 202 when dispatch is accepted. Plan availability, resolved coverage, and credits are still checked by the worker. The request does not wait for the final test result, so an accepted request alone is insufficient for a release decision.

If you see	Check
`400`	The JSON body and required non-empty `message`.
`404`	The complete URL, saved Webhook setting, and Active plan status.
`202`, but no new Run	Plan availability, matching Active cases with steps, and workspace credits.
A failed Run	Investigate the failure using the case result and recording.

Avoid blindly retrying an accepted request: repeated requests can start separate executions.

Check your progress

A deployment produces a saved Run with the intended cases, and the responsible team can find its result.