Outgoing webhooks

Outgoing webhooks send a signed HTTP request to an endpoint you choose when something happens in a project: a test case changes, a run closes, a defect changes status. Use them to post to a chat channel, open a ticket in another tool, or feed your own pipeline.

Each project can have up to 20 webhooks. Each webhook has an endpoint, the events it listens to, a signing secret, and a delivery history.

Before you start

Create a webhook

1. Open the project, select Settings, then select the Webhooks tab.
2. Select New webhook.
3. Fill in the form:
   • Name: how the webhook appears in the list, for example Release alerts in Slack.
   • Endpoint URL: the https:// address that receives the requests.
   • Events: pick one or more. Each selected event sends one request to the endpoint. Events are grouped by the item they concern. Turn on All events to send every event the catalog offers, including events added later.
   • Signing secret (optional): a secret of your own. Leave it empty and Probara generates one.
   • Enabled: a disabled webhook keeps its settings and sends nothing.
4. Select Create webhook. Probara shows the signing secret once, after you save. Copy it into your receiver before you close the dialog.

Manage webhooks

Each webhook in the list has these actions: Edit, Send test, Deliveries, Enable or Disable, Rotate secret, and Delete.

• A disabled webhook keeps its settings. Send test and Redeliver are refused until you enable it.
• Delete stops events to the endpoint and deletes the webhook’s delivery history.

Endpoint rules

Signing secret

Probara signs every request with HMAC-SHA256, following the Standard Webhooks specification. The signature travels in the webhook-signature header. The developer reference shows how to verify it.

• A secret you supply has the form whsec_ followed by 24 to 64 bytes encoded in base64.
• Probara stores the secret encrypted, so it can sign requests. Afterward it shows only the last four characters, so you can tell secrets apart.
• Rotate secret creates a new secret and shows it once. The current secret stops verifying requests as soon as you rotate it, so update your receiver with the new secret right away.

Advanced settings

Open Advanced to change how requests are sent. The defaults work for most endpoints.

HTTP method

POST by default. Choose PUT or PATCH if your receiver expects one of them.

Custom headers

Add up to 20 headers, for example Authorization with a bearer token. You cannot set the names Probara uses itself: Host, Content-Length, Content-Type, Transfer-Encoding, Connection, User-Agent, webhook-id, webhook-timestamp, webhook-signature, or any name starting with cf-. Each name can appear once.

Header values are stored encrypted and never shown again. After you save, Probara shows only the names. To keep a value when you edit the webhook, leave its field empty. Saving replaces the whole list, so a header you remove is deleted.

Payload

• Standard JSON (the default) sends the JSON envelope described in Outgoing webhooks for developers.
• Custom template lets you write the body. Choose a content type (application/json, application/x-www-form-urlencoded, application/xml or text/plain) and a template of up to 16,384 characters.

A body is limited to 256 KiB. A standard envelope over that size drops data first, then changes. A custom body over that size is not sent, and its delivery fails at once with the error The rendered body is larger than 256 KiB.

Put a text placeholder inside the quotes of a JSON string, and Probara escapes it there. A text placeholder whose path does not exist inserts nothing, and {{json ...}} inserts null. For a JSON template, Probara checks on save that it renders valid JSON.

For example, a minimal JSON template:

{
  "text": "{{type}}: {{entity.label}} ({{project.name}})"
}

• Start from a preset fills the template for a Slack, Microsoft Teams or Discord incoming webhook. Use the URL the chat tool gives you as the endpoint. Each preset sends the event type, the entity label, the project name and the actor’s name.

Send a test

Select Send test, choose the Event to sample, and select Send test in the dialog. The list offers the webhook’s events, or every event when All events is on, and it starts with the first one.

Probara sends one sample event right away. The sample uses fixed example values, not your project’s data, and it is flagged as a test in the payload (test is true). It makes one attempt, with no retries. The dialog then shows whether it was delivered, with the response or the error and the time it was sent, and the result is also added to the delivery history. A test never counts toward the failure count, so it cannot disable the webhook.

Delivery history

Each finished delivery (succeeded or failed) is kept for 30 days.

• Each delivery shows its status (Pending, Succeeded or Failed), its number of attempts, and its response.
• Open a delivery to see the request Probara sent (method, URL, headers and body) and the response: status, headers, and up to 4,096 bytes of the response body. Custom header values appear as [redacted].
• Redeliver sends the same event again as a new delivery, linked to the original. It keeps the event ID and body, and it uses the webhook’s current URL, method and headers. Use it after you fix a failing endpoint. Redeliveries count toward the failure count, and a disabled webhook can’t redeliver until you enable it.
• The list shows each webhook as Active, Failing or Disabled. Failing means the webhook is enabled and has had failed deliveries since its last success. A webhook that Probara switched off shows Disabled after failures.

When deliveries fail

An attempt fails when the endpoint does not answer with a 2xx status within 10 seconds, when it redirects, or when Probara cannot reach it. Failed attempts are retried seven times, and the last retry comes at least 10 hours and 42 minutes after the first attempt. The full schedule is in the developer reference.

Probara turns a webhook off automatically when its last 5 deliveries in a row failed and it has had no successful delivery for 72 hours. If it has never succeeded, the 72 hours count from its creation. An email goes to the organization’s owners and admins with the endpoint’s host, when it last succeeded, and a link to the webhook settings.

To resume, fix the endpoint, select Enable, and redeliver the events you still need. Enabling resets the failure count, but not the 72-hour clock. If the last success was more than 72 hours ago, five new failed deliveries in a row disable the webhook again.

Events that send nothing, or one event

• A bulk mark, a bulk result submission or a CI report sends one test_run.results_submitted event for the whole action. A single mark sends result.created.
• Test cases created by an import or a bulk clone send no test_case.created event.
• Reopening a run sends no event.
• Shared steps that belong to the organization rather than to a project send no events.
• While the organization’s plan does not include webhooks, events are dropped, and deliveries that are still pending are not sent. They are sent once the plan includes webhooks again.

Audit trail

Creating, changing or deleting a webhook, rotating its secret, and turning it off automatically are recorded in Workspace activity.

Next step

• For event names, the payload and the signature checks, read Outgoing webhooks for developers.
• To manage webhooks from a script or an AI assistant, see the Webhooks API and the MCP tool reference.

Before you go live

• The endpoint is https:// on a public domain.
• Your receiver verifies webhook-signature against the raw body.
• It answers with 2xx within 10 seconds and does slow work after answering.
• It ignores a webhook-id it has already processed.
• Send test shows a succeeded delivery.