Webhook adapters

Test before you connect

Preview exactly how a provider payload maps, then send a safe end-to-end test.

Before pointing a real monitoring system at WarnFire, you can rehearse in the console — first without any side effects at all, then with a real (but safely fenced) test page.

Before you begin

You need tenant-administrator or tenant-owner access, an unrestricted workspace, a service and integration key , a representative provider payload, and an on-call responder who knows the confirmed test can page them.

Open Services and scroll to the Provider webhook adapters panel.

Preview a mapping

1. Choose the Adapter (for example alertmanager). The panel shows the generic adapter route. Use the provider’s setup page for its exact address and credential placement; Azure, CloudWatch SNS, and GCP differ.
2. Paste a sample payload into Provider payload — the panel starts you off with a realistic example you can edit.
3. Press Preview mapping.

You’ll see precisely what WarnFire would make of it: the incident title, severity, the dedup key used for correlation, links, labels — the whole mapped event. Nothing is sent, nothing is created, no one is paged. Preview as many times as you like.

If the payload has a problem, the preview tells you why in plain terms (for example, an unsupported Alertmanager version) so you can fix your provider’s configuration before going live.

Send a test

When the preview looks right:

1. Pick a service from the dropdown next to Send test.
2. Press Send test and confirm.

This one is real: the mapped event enters the normal ingest, deduplication, incident, and escalation path and pages whoever is on call for that service. It proves mapping through response, but it does not exercise the provider’s network delivery, endpoint, credential transport, or raw HTTP request. Complete the provider guide’s lifecycle test before cutover.

Review the service policy before confirming. Push and email are free; selected SMS and voice deliveries consume allowance or prepaid credits for every destination contacted and can invoke configured auto-recharge. Maintenance windows and tenant delivery settings can intentionally suppress those pages.

Two safety properties to know:

• Test events live in their own lane. WarnFire rewrites the mapped correlation and idempotency identities into a console-test namespace before ingestion. Pasting a production payload therefore does not reuse that payload’s production identities to update or close its live incident.
• Exact repeat clicks don’t pile up. Sending the same mapped test again reuses its test identity and returns the original result. If the provider payload carries its own message ID, do not change the meaning while keeping that ID; WarnFire rejects an idempotency conflict instead of guessing which request you intended.

Verify it worked

After Send test completes, confirm all of the following:

1. The panel reports Test event accepted with a deduplication key and incident identifier.
2. For a trigger sample, one test incident appears under the service you selected.
3. The mapped summary, severity, labels, links, and details match the preview.
4. The service’s on-call responder receives the expected page.
5. The responder acknowledges the incident, then you resolve it with a reason that identifies it as a test.

Next steps

Read Delivery evidence to understand what each channel can prove, then use Delivery Activity to distinguish provider acceptance from confirmed delivery to a responder or device.