# Outbound webhooks

Have Testsnag POST to your own service whenever a run finishes, signed so you can trust it.

> **Plan:** available on the Free plan and above.

Outbound webhooks are the opposite direction from trigger URLs. A trigger URL lets something else start a Testsnag run; an outbound webhook lets Testsnag tell something else that a run has finished. Use them to open an incident, update a status page, gate a deploy, or push results into a dashboard you already have.

![The Webhooks tab showing a configured outgoing endpoint with its signing secret and controls.](https://testsnag.com/images/docs/notifications/outbound-webhooks-1-endpoint.r1.jpg)

Marked on the screenshot:
- The endpoint, with a name and the URL Testsnag POSTs to.
- Per-endpoint switches: send on pass, on fail, or both.
- The signing secret. Verify every delivery against it before acting on the payload.
- Send a test ping to check your receiver before relying on it.
- Rotate the secret if it is ever exposed.

## Adding an endpoint

From a test’s settings, add an endpoint with a name and a URL. Each endpoint has its own notify-on-success and notify-on-failure switches, so you can send failures to an incident channel and successes nowhere at all, which is usually what you want.

The payload includes run.environment, an object with the name of the [environment](https://testsnag.com/docs/building-blocks/environments.md) the run used, or null when it ran with no environment, so your receiver can tell a Staging failure from a Production one.

## Verifying the signature

Every endpoint has a secret, and every delivery is signed with it. Verify the signature before acting on a payload: the URL alone is not proof the request came from Testsnag, and an endpoint that acts on any POST it receives is an open door. The secret can be rotated from the same screen if it is ever exposed.

## Deliveries and retries

Each endpoint keeps a delivery log with the response status of recent attempts, which is the first place to look when your service is not reacting. A failed delivery can be resent from there once the receiving end is fixed, so a brief outage on your side does not silently lose a notification.

> **Warning:** Endpoints should respond quickly and do their real work asynchronously. A slow endpoint delays the delivery rather than the run, but it will show up as timeouts in the delivery log.