Sazabi
Integrations

Generic Webhook

Connect a Generic Webhook so Sazabi can deliver signed issue alert events to an HTTPS endpoint you run.

About

Connecting the Generic Webhook lets Sazabi route issues to an HTTPS endpoint you run — a bridge into alerting and automation systems Sazabi does not integrate with natively. Sazabi triggers an alert at your endpoint when an issue opens and resolves it when the issue closes, and signs every delivery so your endpoint can verify it came from Sazabi.

The Generic Webhook is different from webhook endpoints under Settings > Webhooks, which deliver general notification payloads authenticated with a custom header. The Generic Webhook is an integration connection that delivers issue alert events signed with a shared secret.

Prerequisites

  • An HTTPS endpoint that accepts POST requests. The URL must be publicly reachable — private and internal addresses are rejected.
  • A signing secret you generate and share between Sazabi and your endpoint, used to verify each delivery.
  • Organization admin access in Sazabi.

Set up in the dashboard

The Generic Webhook has no dashboard connect flow — connect and manage it with the Sazabi CLI, described in the next section.

Set up with the CLI

Connect the Generic Webhook with the Sazabi CLI (installed and authenticated — see CLI reference).

The Generic Webhook is an API-key-style provider with two credential fields: webhookUrl (your HTTPS endpoint) and signingSecret. Read the secret from an environment variable rather than pasting it inline:

export WEBHOOK_SIGNING_SECRET=...   # a secret you generate
sazabi integrations connect webhook \
  --credentials "{\"webhookUrl\":\"https://example.com/sazabi/alerts\",\"signingSecret\":\"$WEBHOOK_SIGNING_SECRET\"}"

Run sazabi integrations list to confirm the connection, or sazabi integrations providers --json to see each provider's credential fields. To rotate the secret or change the URL, use sazabi integrations update-credentials.

Notifications

When Sazabi routes an issue to the webhook, it POSTs a JSON payload to your endpoint:

  • alert.triggered when an issue opens — carries a stable alert id, an ISO 8601 timestamp, and an alert object describing the issue.
  • alert.resolved when the issue closes — carries the same alert id, a timestamp, and an optional message.

Every request includes an X-Sazabi-Signature header: the hex-encoded HMAC-SHA256 of the raw request body, computed with your signing secret. Verify it before acting on a payload — compute the HMAC over the exact bytes of the body and compare it to the header value — and respond with a 2xx status to acknowledge the delivery.

Verify

Run sazabi integrations list and confirm the Generic Webhook connection appears as connected. When Sazabi routes an issue to the webhook, your endpoint receives a signed alert.triggered POST whose X-Sazabi-Signature matches the HMAC you compute with the shared secret.

Troubleshooting

Connect fails with a URL error — The webhook URL must use HTTPS and must not point at a private or internal address. Use a publicly reachable hostname.

Signature verification fails at your endpoint — Compute the HMAC-SHA256 over the exact raw request body (no re-serialization) with the same signing secret, and compare the hex digest to the X-Sazabi-Signature header. If the secret was rotated on one side only, update the other with sazabi integrations update-credentials.

Further reading