Generic Webhook

A generic webhook sends Causely's standard notification payload, as JSON, to any HTTP endpoint. Use it to reach systems Causely doesn't support out of the box.

All generic webhook delivery runs through the Causely Mediator, which sends an HTTP POST with the Causely notification payload as the request body.

How you define a generic webhook destination depends on your setup:

• Managed Notifications (recommended)
  The endpoint URL, token, and routing rules are configured in the Causely UI. The UI stores configuration that the Mediator reads at runtime.

• Mediator-based configuration (advanced)
  Define the destination programmatically with a Kubernetes secret or environment variables instead of the UI. Uses the same Mediator delivery path as managed notifications.

For routing rules and filters in the UI, see Set up notification routing in the UI.

When to use a generic webhook vs. Custom Workflows

Use a generic webhook when your endpoint can accept Causely's payload as-is.

If you need to transform the payload or control the exact request format sent to your target system, use Custom Workflows (CauselyBot) instead, which gives you full control over how the webhook is processed and formatted.

Managed Notifications (recommended)

1. Go to Settings → Notifications.
2. If you haven't already selected a processing mode, choose one now. Click Create.
3. Complete the notification configuration:

Field	Value
Name	A descriptive name for the notification
Type	Generic
URL	Your endpoint, for example https://api.example.com/notifications
Token	Optional; see Authentication below

4. Choose the cluster or clusters that handle processing and delivery.
5. Optionally add Notification Filters to control when notifications are sent.
6. Click Create.

Authentication

The Token field maps directly to the HTTP Authorization header. Causely sends whatever you enter verbatim, and it does not add or assume any authentication scheme. This means you are responsible for supplying the full header value, including the scheme keyword, that your endpoint expects.

Your endpoint expects	Enter in the Token field
Bearer token	Bearer <token>
Basic auth	Basic <base64 of user:password>
A raw API key header value	Exactly what the endpoint expects
No authentication	Leave blank

Include the Bearer keyword yourself

If your endpoint uses bearer authentication, enter the full value Bearer <token> in the Token field, including the word Bearer. Causely does not add the Bearer prefix for the generic type.

When the token is left blank, no Authorization header is sent. Requests are always sent with Content-Type: application/json.

Mediator-based configuration (advanced)

If you prefer not to use the UI, define the generic webhook destination directly on the Mediator with a Kubernetes secret or environment variables.

Kubernetes secret

Create a secret labelled causely.ai/notif-config: Generic in the Mediator namespace. Set notif_config_url to your endpoint and, optionally, notif_config_token to the full Authorization header value.

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: generic-notification-config
  namespace: causely
  labels:
    causely.ai/notif-config: Generic
stringData:
  notif_config_filters: "[]"
  notif_config_filters_enabled: "true"
  notif_config_global: "false"
  notif_config_name: generic-webhook
  notif_config_token: "Bearer <token>"   # optional; sent verbatim as the Authorization header
  notif_config_type: Generic
  notif_config_url: https://api.example.com/notifications

Environment variables

Set these on the Causely Mediator deployment. Replace <NAME> with your notification config name.

NOTIFICATION_<NAME>_TYPE=Generic
NOTIFICATION_<NAME>_URL=https://api.example.com/notifications
NOTIFICATION_<NAME>_TOKEN=Bearer <token>
NOTIFICATION_<NAME>_FILTERS_ENABLED=true

Filters

Generic webhook destinations support filters (severity, namespace, entity type, impactsSLO, and more) like other Causely notification targets. Configure them in the create/edit modal in the UI, or via notif_config_filters in the Kubernetes secret.

notif_config_filters is a JSON array. When notif_config_filters_enabled is "false" or the array is empty ("[]"), all notifications pass through. Multiple filters are ANDed: a notification must match all filters to be forwarded.

Field	Description
severity	"Low", "Medium", "High", or "Critical"
name	Problem name (for example, "Malfunction", "CPUCongested")
entity.type	Entity type (for example, "KubernetesService", "ApplicationInstance")
labels.k8s.cluster.name	Kubernetes cluster name
labels.k8s.namespace.name	Kubernetes namespace name
impactsSLO	true if the notification includes impacted SLOs

Supported operators: equals, not_equals, in, not_in.

For example, to forward only High and Critical severity notifications:

notif_config_filters: '[{"field":"severity","operator":"in","value":["High","Critical"]}]'
notif_config_filters_enabled: "true"

For more on configuring filters in the UI, see Managed Notifications.

---

Notification Payload Format

Causely sends the same structured JSON to all webhook destinations, including summaries of causal insights and service impact context.
For an example payload and explanation of each field, refer to the Notification Payload Format page.