Webhook adapters
Webhook adapters
Map provider-specific webhook deliveries into canonical WarnFire events.
Webhook adapters translate external provider payloads into the canonical WarnFire event model. Adapters reuse the normal authorized ingest path, so validation, deduplication, rate limits, incident updates, and escalation behavior remain consistent.
Available adapters
| Adapter | Delivery model | Purpose |
|---|---|---|
| Generic webhook | One delivery, one event | Accept a provider-neutral envelope without custom backend code. |
| Prometheus Alertmanager | One delivery, one alert-group event | Correlate an Alertmanager group into one WarnFire incident. |
| Grafana | One delivery, one alert-group event | Correlate a Grafana alerting group into one WarnFire incident, with dashboard and panel links. |
| PagerDuty Events API endpoint | One event, PagerDuty Events API v2 shape | Accept existing PagerDuty Events API v2 traffic at /v2/enqueue without payload changes. |
| Datadog | One delivery, one monitor event | Turn a Datadog monitor alert into an incident and a recovery into a close. |
| Amazon CloudWatch | One SNS delivery, one alarm event | Turn a CloudWatch alarm delivered through SNS into an incident and a return to OK into a close. |
| CloudWatch via EventBridge | One EventBridge delivery, one alarm event | Carry the same CloudWatch alarms through EventBridge, authenticated with a header instead of a key in the URL. |
| Azure Monitor | One webhook delivery, one alert event | Turn an Azure Monitor alert into an incident and its resolution into a close. |
| Google Cloud Monitoring | One webhook delivery, one alerting-incident event | Turn a Cloud Monitoring alerting incident into a WarnFire incident and its closure into a close. |
| Nagios & Icinga | One notification-command post, one event | Turn a Nagios or Icinga problem into an incident, a recovery into a close, and an acknowledgement into an ack. |
All of these adapters consume provider alarms and alerts — a monitoring rule changing state — not raw logs or metric streams. That state change is what opens and closes an incident.
The console provides a mapping preview that does not ingest an event and a confirmed Send test action that follows the real ingest and paging path.
Create the service and integration key first by following Create a service and its first key . Before changing a production sender, use Preview a mapping and then Send a test to run an isolated mapping-to-escalation check.
Security rule
Authenticate webhook requests using a header or request body supported by the integration. Keys must not be placed in URLs on the generic endpoint. Some providers, including basic Splunk webhook actions, cannot set custom headers; those integrations require a reviewed provider app or another credential transport rather than silently weakening the generic endpoint.
URL-key exceptions
The cloud providers are the reviewed exceptions. Amazon CloudWatch (via SNS), Azure Monitor, and Google Cloud Monitoring all deliver through webhooks that cannot attach a custom header, so their integration key travels in the request URL — the last path segment, or (for GCP’s native token auth) an auth_token query parameter — on a dedicated endpoint, never the generic one. Each such URL is treated as a whole secret. WarnFire’s edge access log replaces credential path segments and the auth_token query value with REDACTED before writing the record. CloudWatch’s SNS endpoint additionally auto-confirms subscriptions only after verifying the URL is a genuine sns.*.amazonaws.com HTTPS endpoint (an SSRF guard). CloudWatch delivered via EventBridge does not need this exception — EventBridge can set a header, so it uses the normal Bearer path.
Alertmanager
Configure send_resolved: true so resolved alert groups close their correlated WarnFire incident. The adapter uses the Alertmanager groupKey for correlation and a deterministic mapped-payload hash for idempotency. Changed visible values create an update; an identical retry does not.
Because correlation follows groupKey, the sender’s group_by decides how many incidents one outage produces — grouping by alertname fans a single failure out into one incident per symptom. See Decide what one incident means
and Delivery timing
for the grouping and timer settings that determine this.
For current request shapes and rejection rules, use the linked adapter guides above and the OpenAPI document .