Webhooks

ContextQA webhook notifications — send test plan results to any HTTP endpoint on completion, enabling integrations with PagerDuty, custom dashboards, and internal tools.

Who is this for? SDETs, developers, and engineering managers who need to forward test results to custom dashboards, PagerDuty, or internal tools that have no pre-built ContextQA connector.

Webhook notification: An HTTP POST request that ContextQA sends to a user-configured URL when a test plan execution completes, delivering a structured JSON payload containing the plan name, result, pass/fail counts, and a link to the execution report.

ContextQA has native integrations for Slack, Jira, MS Teams, and other common tools. But teams also run custom dashboards, internal monitoring systems, PagerDuty escalation chains, and proprietary incident management tools that have no pre-built ContextQA connector. Webhooks solve this: configure any HTTPS endpoint to receive test results the moment a plan finishes, then process the payload however your system requires.

What webhook notifications do

When a test plan execution reaches a terminal state (PASSED, FAILED, or PARTIAL), ContextQA sends a single POST request to every webhook URL configured for that organization. The payload contains enough information for the receiving system to take action without making additional API calls:

• Test plan name and ID

• Execution result (PASSED, FAILED, or PARTIAL)

• Total test case count

• Passing test case count

• Failing test case count

• Execution start time and end time

• Direct URL to the execution report in the ContextQA portal

The webhook fires once per execution completion. ContextQA does not send in-progress updates.

Configuring webhooks in ContextQA

1. Navigate to Settings in the left navigation.

2. Click Organization Settings.

3. Select the Notifications tab.

4. In the Webhook URLs section, click Add Webhook.

5. Enter the target HTTPS endpoint URL.

6. Optionally enter a name for the webhook to identify it in the list.

7. Click Save.

Multiple webhook URLs can be configured. ContextQA sends the payload to all configured URLs when an execution completes. Each URL receives an independent POST request — a failure to deliver to one URL does not affect delivery to others.

To remove a webhook, click the Delete icon next to the webhook entry in the Webhook URLs list and confirm the deletion.

Webhook payload structure

ContextQA sends the following JSON payload as the POST request body:

{
  "planName": "Checkout Flow Regression",
  "planId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "executionId": "x9y8z7w6-v5u4-3210-tsr-qpon98765432",
  "result": "FAILED",
  "totalTests": 47,
  "passedTests": 44,
  "failedTests": 3,
  "startTime": "2026-03-15T14:00:00.000Z",
  "endTime": "2026-03-15T14:18:32.000Z",
  "reportUrl": "https://app.contextqa.com/executions/x9y8z7w6-v5u4-3210-tsr-qpon98765432",
  "environment": "Staging"
}

The Content-Type header of the POST request is application/json. The result field is always one of PASSED, FAILED, or PARTIAL. Parse this field to determine whether to trigger alerts.

Connecting to systems without a built-in ContextQA integration

PagerDuty

To send ContextQA failures to PagerDuty:

1. In PagerDuty, create an Events API v2 integration on the target service. Copy the Integration Key.

2. Deploy a lightweight webhook relay (an AWS Lambda, Google Cloud Function, or similar) that:

   • Receives the ContextQA webhook POST

   • If result == "FAILED", sends a PagerDuty event with event_action: "trigger" and maps planName, failedTests, and reportUrl to the PagerDuty payload fields

   • Otherwise, sends no PagerDuty event or sends a resolve event

3. Configure the relay's HTTPS endpoint as the webhook URL in ContextQA.

Custom dashboards

Internal dashboards that track test health over time can consume webhook payloads directly. The receiving endpoint should:

1. Parse the payload and extract planId, result, passedTests, failedTests, and endTime.

2. Write these fields to your time-series database or dashboard data store.

3. Return HTTP 200 immediately — ContextQA does not wait for the receiver to process the data before considering delivery complete.

Slack (custom channel routing)

If ContextQA's built-in Slack integration does not support the routing logic you need (for example, sending different plans to different channels based on the plan name), use a webhook connected to a Slack incoming webhook URL or to a custom Slack bot endpoint that applies your routing logic.

n8n, Zapier, and Make

Automation platforms like n8n, Zapier, and Make can receive webhooks directly. Create a webhook trigger node in your automation and paste the generated URL into the ContextQA webhook configuration. These platforms can then fan out notifications to any downstream service they support.

Verifying webhook delivery

ContextQA does not currently provide a webhook delivery log in the portal UI. To verify that webhooks are being sent correctly:

• Use a service like webhook.site or Beeceptor to create a temporary endpoint and test delivery before pointing to your production system.

• Check your receiving endpoint's access log after a test plan execution completes to confirm the POST arrived.

• Use the execution report URL from the ContextQA portal to verify that the reportUrl field in the payload resolves to the correct execution.

Security considerations for webhook endpoints

Webhook endpoints are publicly reachable HTTPS URLs. Treat them with the same security posture as any external-facing API endpoint:

Use HTTPS exclusively. ContextQA sends webhook payloads only to HTTPS URLs. HTTP endpoints will not receive delivery. HTTPS ensures the payload is encrypted in transit.

Validate the payload source. ContextQA does not currently sign webhook payloads with an HMAC secret. Because of this, your endpoint should validate that incoming requests are plausible ContextQA payloads by checking that required fields (planId, executionId, result) are present and well-formed before acting on the payload. Do not take destructive actions (creating incidents, sending pages) based on a malformed or unexpected payload.

Rate-limit your endpoint. Each execution completion sends one POST per configured webhook URL. For organizations with high-frequency test execution (dozens of plan completions per hour), ensure your endpoint can handle the incoming request rate without becoming a bottleneck.

Restrict endpoint access where possible. If your infrastructure supports IP allowlisting, consider allowlisting ContextQA's outbound IP ranges to reduce the risk of spoofed webhook requests. Contact ContextQA support for the current list of outbound IP addresses.

Return 200 quickly. ContextQA considers delivery successful when it receives an HTTP 200 response. Process the payload asynchronously if your handling logic is slow — enqueue the payload and respond immediately, then process in the background. A slow endpoint may cause ContextQA to time out the delivery attempt.

Frequently Asked Questions

Does ContextQA retry failed webhook deliveries?

ContextQA makes a best-effort delivery attempt. If the endpoint is unavailable or returns a non-200 response, the behavior depends on your subscription tier and ContextQA's retry policy. For critical alerting, design your receiving endpoint to be highly available and idempotent, and supplement webhooks with the native Slack or email notification channels for redundancy.

Can I configure different webhooks for different test plans?

The current webhook configuration in Settings → Organization Settings → Notifications applies to all test plan executions in the organization. Filtering by plan is done on the receiver side — use the planId or planName field in the payload to route notifications to the appropriate endpoint or suppress them for plans you do not want to alert on.

Can I test a webhook without running a full test plan?

ContextQA does not provide a "send test payload" button in the current UI. Use a test endpoint service (webhook.site, Beeceptor) to inspect the payload format by running a short test plan and examining what arrives at the test endpoint. Once the format is confirmed, reconfigure to your production endpoint.

What happens if two plans finish at nearly the same time?

ContextQA sends independent POST requests for each execution completion. Two concurrent completions result in two POST requests, potentially arriving at your endpoint within milliseconds of each other. Ensure your endpoint handles concurrent requests correctly.

Related

• Slack integration

• Jira integration

• GitHub Actions integration

• Jenkins integration

• Exporting reports

Connect ContextQA to your CI/CD pipeline in 15 minutes. Book a Demo → — See the full integration walkthrough for your existing toolchain.