If your team does anything beyond logging into Qase and clicking around manually, webhooks are a great way to connect Qase to the rest of your toolchain.

Every meaningful event in Qase, a run completing, a defect being filed, a test case updated, can fire a payload to an endpoint you control. What you do with that is up to you.

Some common uses teams wire up: triggering a CI/CD pipeline step when a run finishes, syncing Qase defects to an internal dashboard, or logging test activity into an observability tool. If you've ever found yourself manually updating another system after something happens in Qase, a webhook could be used instead.

Webhooks are configured at the project level under Settings → Webhooks.

Each webhook needs a title, a publicly accessible endpoint URL, and a secret, sent as an X-Qase-Secret header so your server can verify the request is genuinely coming from Qase.

You can enable multiple event triggers per endpoint, or set up separate webhooks for separate concerns if you'd rather keep them cleanly separated.

For the full payload structure for each event, refer to Qase's webhook payload reference.

Qase fires webhooks across most of its core entities - test cases, suites, plans, runs, results, defects, milestones, shared steps, custom fields, and reviews. A few events worth calling out specifically:

Test run start / complete / aborted are the most broadly useful. A run completing is a natural trigger for downstream actions, posting a summary to Slack, updating a release dashboard, or kicking off a report generation script.

Create defect / resolve defect are useful if you're building any kind of cross-tool defect visibility. A new defect firing a webhook means you can notify a dev channel or create a mirrored ticket in another system the moment it's logged.

Result events are where automation frameworks typically hook in, if you're pushing automated test results into Qase via the API, you can use result webhooks to trigger follow-on actions based on what passed or failed.

Can one endpoint receive multiple event types?

Yes, you can subscribe a single endpoint to as many events as you want. If your receiving server needs to handle them differently, use the event type in the payload to route accordingly.

How do I verify that incoming requests are actually from Qase?

Use the secret you configured. Qase sends it as an X-Qase-Secret header with every request, validate it on your server before processing the payload.