Webhooks

Webhooks are the lowest-friction integration ISE has: the sender needs a URL and a token, not a connector. Events land on the Events screen for visibility, and alert-level events raise ordinary alert signals — flowing onto incidents through exactly the same severity ladder, thresholds, and correlation as every native integration.

Capabilities

Events. Any system that can POST JSON can tell ISE something happened — a deploy, a CI run, a change. Events are stored durably, badge success/failure outcomes, and appear on the Events screen with their source’s name.

Alert signals. An event with level: alert raises a real alert signal: severity maps onto the canonical ladder (by default alert → high, warn → medium, info → info, tunable per source), duplicates of the same alert_key attach as recurrences, and the auto-incident threshold and correlation apply unchanged.

Entity resolution. An entity hint in the payload is matched against estate names and aliases. Matched, the signal joins the entity graph; unmatched, it stands alone — ISE never invents an entity from a hint.

Recovery. Push sources can’t be polled, so two mechanisms clear alerts: the sender POSTs status: recovered with the same alert_key, and a per-source alert TTL can auto-recover anything not re-fired within its window — a source that goes silent never leaves a signal firing forever.

Trust posture. Event content is data, never instructions: whatever a sender writes in title or detail is information ISE stores and may show — including to its AI as context — but never treats as a command.

Setup

1. Register a webhook source (Settings → Webhooks) with a name and description. ISE mints a unique secret token; the per-source ingest URL carries it — the URL is the credential, so treat it like one.
2. Point the sending system at the URL. ISE defines the payload schema (the source screen generates a sample curl); writing the adapter from the sender’s native format is the sender’s side of the contract. Unknown fields are preserved verbatim, so nothing a sender includes is lost.
3. Optionally set the source’s alert TTL and severity mapping.
4. The token is rotatable, and the source can be disabled or deleted at any time — unknown or disabled tokens are rejected at ingest.

Examples

A deploy event for visibility:

curl -X POST "$ISE_WEBHOOK_URL" -H 'Content-Type: application/json' -d '{
  "title": "kora v2.41.0 deployed to production",
  "event_type": "deploy",
  "outcome": "success",
  "entity": "kora"
}'

It appears on the Events screen against the kora service — context an investigation can line up against any incident that follows.

An alert that opens an incident:

curl -X POST "$ISE_WEBHOOK_URL" -H 'Content-Type: application/json' -d '{
  "title": "Backup job failed on nas-01",
  "level": "alert",
  "alert_key": "backup:nas-01",
  "entity": "nas-01",
  "detail": "rsync exited 23; 3 consecutive failures."
}'

A high-severity signal opens an incident on nas-01. When the job succeeds again, the sender POSTs the same alert_key with "status": "recovered" and the incident resolves — or the source’s TTL cleans it up if the sender never says.

A sensible wiring pattern. Most systems’ outbound webhooks won’t match ISE’s schema directly — put a thin adapter (a small script or serverless function) between them that maps the native payload onto title/level/alert_key/entity and forwards the rest; the extra fields are kept verbatim on the event.