Skip to main content
This guide walks you through setting up a Clarion Generic Webhook monitor — a flexible endpoint that accepts JSON events from any service that can make an HTTP POST request. Use it to bring custom alerts, deploy events, CI failures, or any JSON payload into Clarion.
Estimated time: 5 minutes. You will need a Clarion workspace and the ability to configure outbound webhooks in the source service.

​
Prerequisites

  • A Clarion workspace
  • A service that can send HTTP POST requests with a JSON body (CI systems, bespoke scripts, SaaS tools with webhook outputs, Slack-style senders, etc.)

​
Step 1 — Create a Generic Webhook monitor

  1. In Clarion, go to Settings > Integrations
  2. Find Webhook and click Add Monitor
  3. Give the monitor a name — it is prefixed onto issue titles, so different monitors are easy to tell apart
  4. Pick an authentication method (see the next section)
  5. Pick a default severity for issues opened by the monitor
  6. Click Create
Clarion generates a webhook URL and, depending on the auth method, a signing secret or bearer token. Copy them right away.
Copy any generated secret immediately — it is only displayed once. You can rotate it later from the monitor’s Configure page, but you cannot view the current value.

​
Step 2 — Choose an authentication method

“No authentication” accepts any POST. Only use it for traffic that is already restricted by a private network or VPN.
The authentication method is fixed at creation. To switch, create a new monitor.

​
Signature format

Some senders cannot put their signature in our header. With HMAC auth selected, the Signature format dropdown adds that sender’s header to what the monitor accepts: Unlike the authentication method, this can be changed at any time — it does not affect your secret.

​
Senders that sign a timestamp with the body

Some senders — Immunefi and Slack among them — do not sign the body alone. They send a Unix timestamp in a second header and sign the two joined together, so a captured delivery cannot be replayed later. Under Custom header, fill in Timestamp header to accept those: A digest may arrive with a sha256=, sha512= or version (v1=) prefix — Clarion strips it before comparing. Both header values must stand alone: the timestamp header holds bare digits, and the signature header holds the digest (with at most one of those prefixes). A sender that packs both into a single header — Stripe’s Stripe-Signature: t=…,v1=… — is not covered.
Once a timestamp header is set, the monitor stops honouring body-only digests in X-Webhook-Signature — otherwise the replay window you just configured would sit next to a door that ignores it. Deliveries outside the window are refused with 401 and recorded on the monitor’s health as a stale timestamp, told apart from a wrong secret, so a sender whose clock has drifted is diagnosable.
Example: Immunefi
Immunefi sends X-Immunefi-Signature: v1=<hex HMAC-SHA256> and X-Immunefi-Timestamp: <unix seconds>, signing timestamp + "." + raw body, and recommends a five-minute tolerance. That is: Verify it yourself against the monitor’s secret:

​
Step 3 — Send events from your service

Point the source service at the webhook URL Clarion gave you. Use POST with a JSON object body, up to 100 KB.

​
Minimal example

​
What goes in the payload

Any valid JSON object is accepted. Clarion looks at the payload’s type, event, eventType, or event_type field (in that order) to derive an event type — used for matching filters and included in the issue title. If none of those fields is present, the event is treated as generic. Fields used by the default issue template: All other fields are attached to the issue for reference — no field is dropped.

​
Optional headers

​
The default “All webhook events” filter

When you create the monitor, Clarion adds an All webhook events filter that opens an issue for every incoming event with the default severity you chose. From the monitor’s Configure page you can:
  • Change the default severity — it applies to the default filter immediately
  • Disable the default filter if you only want issues for specific events
  • Add more filters that match by event type, payload fields, or conditions (e.g. only alert when severity = critical)
Each issue’s title includes the monitor name and the time the event arrived; the description surfaces common payload fields (message, severity, source) alongside the event type.

​
Using as a Slack replacement

Many services offer a “Slack incoming webhook URL” field for sending notifications. Because the Generic Webhook accepts arbitrary JSON, you can drop the Clarion webhook URL into those fields instead — your notifications become Clarion issues that get triaged by AI agents. To set this up:
  1. Create a Generic Webhook monitor with No authentication (most Slack-style senders don’t sign requests) or Bearer token if the source service lets you add an Authorization header
  2. Copy the webhook URL from the monitor
  3. In the source service, paste the Clarion webhook URL wherever it asks for a Slack webhook URL
  4. Send a test notification — it will appear as an issue in Clarion
Slack-compatible senders usually put the notification body in a text field, which isn’t one of the event-type fields Clarion looks at — so those events are treated as generic and the default All webhook events filter still catches them.For nicer issue titles, edit the default filter’s title template to reference the fields your sender actually uses (for example {{text}} for Slack-style payloads).

​
What happens next

Once configured, Clarion will automatically:
  • Accept JSON events at the monitor’s webhook URL
  • Apply the default All webhook events filter (and any custom filters you add) to open issues
  • Triage incoming issues using AI agents and surface actionable insights