Skip to main content
Inbound webhooks are how your Git provider (GitHub or GitLab) notifies Stout when something happens in a repo, so a PR Reviewer run can fire. When you connect the GitHub App, Stout registers the webhook it needs automatically. You can also configure an inbound webhook manually — for GitLab, or a self-hosted setup — so repository events reach Stout directly.

Configuring an inbound webhook

From Settings → Integrations → Webhooks → Add Webhook:
  1. Providergithub or gitlab. (No other providers are supported today.)
  2. Stout generates a callback URL and a secret. Copy both and add them as a webhook in your provider’s repository settings.
  3. Your provider signs each delivery, and Stout verifies it: the x-hub-signature-256 header (HMAC-SHA256 of the raw body) for GitHub, or the x-gitlab-token header for GitLab.
The secret is shown once, when the webhook is created, and masked afterward. Copy it before closing the dialog.
Once configured, each incoming delivery is recorded under Recent Events on the Integrations page, so you can see whether Stout received, verified, and acted on it.

What an event does

A pull_request event on a repo that has a configured PR Reviewer creates a review run for that PR. Stout verifies the signature, matches the repo (and any path prefixes), and starts the run. Events that don’t match an enabled reviewer are recorded and ignored.

Alert webhooks (outbound)

Not yet in the dashboard. Outbound alert webhooks — Stout POSTing JSON to a URL of yours when a box goes unhealthy, heartbeats stop, error rates spike, or a resource hits a threshold (health_low, heartbeat_lost, error_spike, resource_high) — are on the roadmap but not yet configurable in the UI. Until they ship, poll the HTTP API for box and run state.