Webhook adapters

PagerDuty Events API endpoint

Point any tool that has a PagerDuty integration at WarnFire by changing one setting — the events endpoint.

Most monitoring tools already ship a built-in PagerDuty integration. WarnFire speaks the same Events API v2 format, so in many cases you can connect a tool to WarnFire without any WarnFire-specific setup — you reuse the PagerDuty integration the tool already has and simply point it at WarnFire.

Before you begin

• A WarnFire service and integration key for these alerts. If you do not have one, create the service and its first key .
• A tool whose PagerDuty (or “Events API v2”) integration lets you change the events endpoint URL. This is the one thing to check — see below.

Connect a tool

In the tool’s PagerDuty integration settings:

1. Set the integration key (sometimes called routing key or service key) to your WarnFire integration key.

2. Set the events endpoint URL to:

   https://api.warnfire.com/v2/enqueue
   

That’s it. Triggers open incidents and page your on-call responder; resolves close them.

The one thing to check: can you change the URL?

Some tools let you override the PagerDuty endpoint URL — those work with the steps above. Others hard-code it to PagerDuty’s own address and only expose the key field. When the URL is locked, most tools still connect through their own custom webhook: you send the same WarnFire message (shown under Sending directly ) to the WarnFire URL. The tables below tell you which path each tool takes.

Tools you can connect

Point the tool straight at WarnFire

These let you set the endpoint URL, so you reuse their built-in PagerDuty (or HTTP) integration and just change the address to https://api.warnfire.com/v2/enqueue.

Use the tool’s custom webhook

These lock the PagerDuty URL to PagerDuty’s own address, but their custom webhook lets you send any message to any URL. Point that webhook at https://api.warnfire.com/v2/enqueue and paste the WarnFire message from Sending directly — no other WarnFire setup needed.

Not yet — a built-in adapter is planned

These tools send a fixed message format that WarnFire does not map yet, so a dedicated adapter is needed: Sentry, Splunk, and Honeycomb. Do not point a fixed provider payload directly at WarnFire’s generic endpoint. The generic adapter requires the canonical WarnFire JSON body plus an Authorization or X-WarnFire-Integration-Key header. Until a provider adapter is available, use a trusted intermediary that transforms the payload and injects the credential, or use a webhook option that can do both itself.

A note on Splunk: its PagerDuty app has an “Integration URL” field, but it only accepts the key, not a full address — so it can’t be pointed at WarnFire. Use Splunk’s webhook path instead.

Sending directly

Any system that can make an HTTPS request can use the same endpoint. The integration key travels in the body as routing_key — never in the URL.

curl --fail-with-body -X POST https://api.warnfire.com/v2/enqueue \
  -H "Content-Type: application/json" \
  -d '{
    "routing_key": "wf_live_your_integration_key_here",
    "event_action": "trigger",
    "dedup_key": "checkout/high-error-rate",
    "payload": {
      "summary": "Checkout error rate above 10%",
      "source": "checkout-api",
      "severity": "critical",
      "component": "checkout",
      "custom_details": { "error_rate": "12%", "region": "us-east-1" }
    }
  }'

To close the incident later, send the same dedup_key with "event_action": "resolve". On a successful trigger, the response returns the dedup_key to use:

{ "status": "success", "message": "Event processed", "dedup_key": "checkout/high-error-rate" }

If you don’t supply a dedup_key on a trigger, WarnFire generates one from the alert’s content and returns it — a retry of the same alert resolves to one incident rather than duplicating.

What shows up on the incident

Event actions

• trigger — opens or updates the incident for that dedup_key.
• acknowledge — records the source system’s acknowledgement on the incident timeline (requires dedup_key). It does not stop escalation. Only a human responder acknowledgement inside WarnFire stops paging.
• resolve — closes the incident (requires dedup_key).

Verify it worked

1. Send a disposable trigger from the connected tool, or use the direct curl request above with a unique dedup_key.
2. Confirm that one incident opens for the intended service and its on-call responder is paged.
3. Send acknowledge with the same dedup_key. Confirm that the source acknowledgement appears on the incident timeline while the incident remains triggered and paging remains active.
4. Have a human responder acknowledge the incident in WarnFire and confirm that escalation stops.
5. Send resolve with the same dedup_key and confirm that the same incident closes.

These requests follow the real 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.

If your tool gets an error back

Next steps

Review Delivery Activity to confirm what WarnFire can prove after the provider accepts each notification.