Webhooks

Webhooks allow you to forward alert data to external systems in real-time. When an alert is triggered in PolicyClue, the alert details are automatically sent as a JSON payload to each configured webhook URL. This enables integration with SIEM tools, ticketing systems, chat applications, or any other service that accepts HTTP requests.

How to Configure

Open the portal, select your tenant, and click "Webhooks" under the Administration menu. Click "Create Webhook" to add a new integration.

Each webhook requires:

• Name – A friendly label to identify the webhook (e.g., "Slack Alerts" or "Splunk SIEM").
• URL – The endpoint that will receive alert data. Use HTTPS for secure transmission.
• Method – Choose POST (default) or PUT depending on what your target system expects.
• Enabled – Toggle to activate or deactivate the webhook without deleting it.

Optionally, you can add custom headers for authentication. Enter one header per line in the format Header-Name: value. For example:

Authorization: Bearer your-api-token
X-Custom-Header: some-value

Security Warning

If you enter an HTTP URL (instead of HTTPS), the portal displays a warning. Using HTTP means your alert data-including user emails, hostnames, and policy details-will be transmitted unencrypted. Always prefer HTTPS endpoints for production use.

Payload Format

When an alert is triggered, PolicyClue sends a JSON payload to your webhook URL. The payload includes:

{
  "alert_id": "abc123xyz",
  "tenant_id": 1,
  "event": {
    "name": "DLP_CONTENT_BLOCKED",
    "created": "2026-01-29T12:00:00.000Z",
    "reason": null,
    "severity": "high",
    "state": "open"
  },
  "url": {
    "domain": "example.com"
  },
  "policy": {
    "id": 42,
    "name": "Sensitive Data Policy"
  },
  "user": {
    "id": "user-browser-id",
    "email": "user@company.com",
    "name": "John Doe"
  },
  "user_agent": {
    "name": "Chrome",
    "version": "120.0.0"
  },
  "host": {
    "name": "WORKSTATION-01"
  },
  "observer": {
    "version": "1.8.0",
    "type": "browser"
  },
  "dlp": {
    "group": {
      "id": 5,
      "name": "Credit Cards"
    },
    "pattern": {
      "id": 12,
      "name": "Visa Card Number"
    },
    "match": {
      "value": "****-****-****-1234"
    }
  },
  "file": {
    "name": "report.pdf",
    "size": 25640
  },
  "portal_url": "https://portal.policyclue.com/alerts/abc123xyz?tenant=1"
}

Field naming (ECS)

Starting with version 1.8.0, webhook payloads use Elastic Common Schema (ECS) field names throughout. Alert metadata is nested under event.* (e.g. event.name, event.created, event.severity, event.state), policy information under policy.*, DLP details under dlp.*, user identity under user.*, browser info under user_agent.*, and the hostname under url.domain. If your integration relies on the previous flat field names (e.g. alert_type, @timestamp, policy_id, dlp_group_id), update your mapping accordingly.

Fields may be null if not applicable to the alert type. For example, DLP fields are only populated for DLP-related alerts.

Use Cases

• SIEM Integration – Forward alerts to Splunk, Elastic SIEM, or Microsoft Sentinel for centralized security monitoring.
• Ticketing Systems – Automatically create tickets in Jira, ServiceNow, or Zendesk when critical alerts occur.
• Chat Notifications – Send alerts to Slack or Microsoft Teams channels using their incoming webhook features.
• Custom Automation – Trigger workflows in Zapier, n8n, or custom scripts based on alert data.

Troubleshooting

Webhooks are sent synchronously when alerts are created. If your endpoint is slow or unreachable, it will not block alert creation, but the webhook delivery may fail silently. Check your target system's logs to verify receipt.

For debugging, you can use a service like webhook.site to inspect the exact payload PolicyClue sends.