Webhook adapters

Generic webhook

Connect a tool that can send WarnFire's JSON shape and an authentication header.

Many tools can send a webhook — a small message posted to a web address when something happens. The generic adapter accepts a tool directly only when it can send WarnFire’s exact JSON shape and attach an authentication header. A tool with a fixed provider-specific payload needs its dedicated WarnFire adapter or a trusted intermediary that transforms the payload and injects the key.

Before you begin

You need:

• a WarnFire service and integration key for the alarms this tool will send. If you do not have one, create the service and its first key ; and
• a sending tool that can post JSON and set either an Authorization or X-WarnFire-Integration-Key header.

The address and the key

Send a POST request to:

https://api.warnfire.com/v1/integrations/webhooks/generic

Include your service’s integration key as a header — either of these works:

Authorization: Bearer YOUR-INTEGRATION-KEY
X-WarnFire-Integration-Key: YOUR-INTEGRATION-KEY

Never put the key in the web address itself, and never in the message body.

What to send

One JSON message per problem event. To open an incident:

{
  "event_action": "trigger",
  "dedup_key": "checkout-api/high-error-rate",
  "client_event_id": "delivery-0001",
  "payload": {
    "summary": "Checkout error rate above 10%",
    "source": "prometheus",
    "severity": "critical"
  }
}

And when the problem clears, close it with:

{
  "event_action": "resolve",
  "dedup_key": "checkout-api/high-error-rate",
  "client_event_id": "delivery-0002"
}

The three fields that matter most:

• event_action — trigger opens (or updates) an incident, resolve closes it.
• dedup_key — your name for this particular problem. Use the same value in the trigger and its resolve so they connect. While an incident is open, repeat triggers with the same dedup_key become updates, not duplicates.
• payload.summary / source / severity — required on every trigger: a one-line human description, where it came from, and one of critical, error, warning, info.

You can also attach a longer description, links to dashboards or runbooks, labels, tags, and typed details. The generic adapter uses the canonical event schema in the public OpenAPI document .

Rules worth knowing

• One event per delivery. A batch of several events in one request is rejected — this keeps “did it work?” a yes-or-no answer for your sending tool.
• Unknown fields are rejected, which catches typos like sevrity before they silently lose information.
• Messages are limited to 256 KiB (262,144 bytes).
• A 429 response means the trigger-rate limit or maximum active-incident limit was reached. Check Limits and protections , resolve stale incidents, and then retry.

Not sure your tool’s output matches? Paste a sample into the console tester first — see Preview a mapping .

Verify it worked

1. Follow Test before you connect , choose generic, and preview a representative trigger event. Confirm the mapped action, title, severity, correlation key, and metadata. Preview does not select or verify a service.
2. Choose the intended service for Send test, send the confirmed test, and verify that one test incident opens for that service and pages its on-call responder.
3. Send a trigger from the real tool, then send a resolve event with the same dedup_key. Confirm that one incident opens and that the same incident closes.

Send test and requests from the real tool follow the normal incident and escalation path. They can page responders; selected SMS and voice deliveries consume allowance or prepaid credits and can invoke configured auto-recharge. Notify the responder before testing.

Next steps

Use Preview a mapping again whenever the sending tool’s payload changes, before changing the production webhook.