Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.siftstack.com/llms.txt

Use this file to discover all available pages before exploring further.

Webhooks in Sift enable sending real-time notifications to external systems when specific events occur, such as when a Rule is violated or resolved. Each webhook includes a trigger event, a customizable payload, and a destination URL that receives the data via an HTTP POST request. Webhooks only fire during live Rule evaluations and do not execute when Rules are run on historical data.

​
Settings

The following table describes each setting available when creating or editing a webhook.

​
Trigger event types

When creating a webhook, you must select a trigger event type. The following trigger event type is available:

​
Built-in variables

Each trigger event type includes a set of built-in variables available when creating or editing a webhook. These variables can be used to customize the webhook payload with dynamic, event-specific data.

​
Rule Violation

The following table lists the built-in variables available for the Rule Violation trigger event type.

​
Webhook payloads

Webhook payloads define the content sent to the destination URL when a webhook fires. Payloads are fully customizable and can be formatted as either plain text or JSON. Each payload can include built-in variables specific to the selected trigger event type, allowing dynamic insertion of relevant data such as Rule names, statuses, and timestamps. Sift provides predefined payload templates for services like Slack, OpsGenie, Jira, and PagerDuty. These can be selected from the Payload config template list during webhook creation or editing. The payload editor supports control flow, including if-else logic for dynamic formatting. For example: 
{
  "blocks": [
    {
      "type": "section",
      "text": {
        "type": "mrkdwn",
        "text": "{{if eq .Status \"resolved\"}}:white_check_mark: Resolved{{else}}:bangbang: *Alert - {{.Status}}*{{end}}"
      }
    }
  ]
}

​
Custom HTTP headers

When configuring a webhook, you can optionally define HTTP headers to customize how the receiving system handles the request. These headers are sent along with the webhook payload.

​
Secure webhooks

Sift supports secure webhook delivery using HMAC-SHA256 signatures. These signatures ensure the webhook was sent by Sift and has not been tampered with in transit. Webhooks are only signed if your Sift environment has a webhook signing key configured. If no signing key exists, webhooks will not include an X-Sift-Signature header and should not be trusted for secure operations. Once a signing key is configured, each outgoing webhook will include a signature header computed using the following formula: 
HMAC_SHA256(signing_key, sent_at + raw_payload)
The sentAt value must be present in the payload to successfully validate the signature. This value is not included automatically. You must explicitly add it using {{.SentAt}} in your webhook payload template. Without it, signature verification will fail.

​
Role-based access control

Webhooks follow Sift’s standard RBAC model. The following table describes the permissions available for each role.
Insufficient permissions: Unauthorized users who attempt to access restricted pages by entering the URL directly will be redirected to the Manage page and shown a warning indicating insufficient permissions.

​
Behavior

The following table describes known constraints and behaviors to be aware of when working with Webhooks in Sift.