Run browser tests with a deploy webhook

Trigger Monito browser tests after deployment with a bearer-authenticated curl call. Queue a suite, pass a preview URL and read results in the dashboard.

Deployments · Checked 2026-10-23

Send an HTTP POST after a successful deploy to queue your project's tests. The webhook works from any pipeline that can run curl after a deploy.

How it works

  1. Your deployment pipeline sends a POST with the project's bearer secret after the deploy succeeds.
  2. Monito queues the selected saved tests and runs them in the browser against the chosen environment or override origin.
  3. The HTTP response returns queued run IDs and a results URL. The eventual verdict and browser evidence land in the dashboard.

Set it up

Pro or Team. Creating this integration requires an active plan; browser runs use your Monito credits. Plan details

  1. Open the project's Automations, then Deploy webhook. Generate its secret and copy the webhook URL.
  2. Store MONITO_WEBHOOK_URL and MONITO_WEBHOOK_SECRET in your deployment environment. The secret is shown only when rotated.
  3. Run the curl call after successful deployment. With no body or query overrides, the webhook uses the automation's saved environment and suite. If no environment is saved, it uses the project's default environment; if no suite is saved, it runs all tests. Replace the example names to override those selections.
Configuration · bash
curl -fsS -X POST "$MONITO_WEBHOOK_URL" \
  -H "Authorization: Bearer $MONITO_WEBHOOK_SECRET" \
  -H "Content-Type: application/json" \
  -d '{"env":"Staging","suite":"Smoke"}'

Run after deployment. Store the secret in your pipeline's secret store, not in this script.

Optional JSON body

env selects an environment by name; if omitted from both the body and query string, the automation's saved environment applies, falling back to the project's default environment only when none is saved. suite selects a suite by name; if omitted from both, the automation's saved suite applies, falling back to all tests only when none is saved. Body values take precedence over query values. scenarioIds selects explicit scenario IDs. baseUrlOverride supplies a transient origin such as a preview deployment URL.

Example result

Example result: field names from the CLI, values illustrative

A separate CLI check --json can diagnose a deployed journey with these fields. This is a browser-verdict example, not the webhook response: HTTP 202 returns queued IDs and a results URL before the tests finish.

Illustrative result · JSON
{
  "checkId": "check_example",
  "projectId": "project_example",
  "runId": "run_example",
  "done": true,
  "status": "failed",
  "cause": "product_defect",
  "causeLabel": "App bug",
  "durationMs": null,
  "creditsCharged": null,
  "reportUrl": "https://www.monito.dev/session/session_example",
  "firstFailure": "The cart total does not include shipping."
}

Limits to account for

202 Accepted means runs were queued. It does not mean tests passed, and it does not hold the deployment open for a verdict. Use the CI integration if the job must wait and fail on test failure.

baseUrlOverride replaces the target origin only. It preserves scenario paths and does not extend saved-login approvals to a preview origin.

Rotating immediately invalidates the previous secret. Update MONITO_WEBHOOK_SECRET before the next trigger. Disabling or deleting the webhook makes subsequent calls return 401.

Comparable benchmark runs

Our team published these runs in the reliability benchmark. They show comparable browser journeys, not executions of the configuration or illustrative result above. Run your own scenario before relying on this integration.

Benchmark method and limits

Read the full guide

All integrations