Connecting Other Destinations

Choose a native notification channel or shape a webhook body for another destination.

Slack, Microsoft Teams, PagerDuty and Jira Service Management each have a native channel type: Fleetera formats and sends to them itself. Everything else goes through a webhook channel, which sends a structured, signed JSON payload (see the Payload Reference) rather than a message shaped for any one tool. Some destinations accept arbitrary JSON directly; for a different body shape, use a webhook body template. A relay can still add processing that needs more than a template.

This page says which channel to use for the common destinations, and gives a quick way to test any webhook endpoint.

For a webhook channel, verify the HMAC signature at the point that first receives the request — your transformer, relay, or workflow — before forwarding the alert onward.

Slack

Slack does not need a webhook channel at all. Create a Slack channel instead: you paste a Slack incoming webhook URL, and Fleetera formats and posts the message itself. There is no relay to run, no payload to map, and no signature to verify.

See Slack Notifications for the full walkthrough — creating the incoming webhook, the Include resolve notifications switch, sending a test, and reading the delivery log when a message does not arrive.

A webhook channel is still the right choice for Slack in one case: when you want Fleetera's raw signed payload rather than a ready-made message, because something of yours processes the alert before — or instead of — posting it. Point the channel at a relay you control (for example, a serverless function) that verifies the signature, does its work, and posts to Slack itself. A classic Slack incoming webhook expects a body shaped like {"text": "..."} or Slack Block Kit, so a webhook channel aimed straight at one sends a body Slack will not render.

Microsoft Teams

Create a Microsoft Teams channel and paste a Teams Workflows callback URL. Fleetera sends the formatted message to the workflow, which posts it to the chosen destination. Turn on Include resolve notifications to include recovery messages.

See Microsoft Teams for workflow setup, adding the channel, replacing its secret URL, and checking delivery.

PagerDuty

PagerDuty does not need a webhook channel either. Create a PagerDuty channel instead: you paste the integration key of a service's Events API V2 integration and pick the service region, and Fleetera triggers, acknowledges and resolves the incident itself, keyed on the alert so repeats land on the open incident.

See PagerDuty for the full walkthrough: creating the integration, the service region, the severity mapping, sending a test incident, and reading the delivery log.

A webhook channel pointed at a transformer you host, or at a PagerDuty Custom Event Transformer, still works. It is the right choice only when something of yours must reshape or enrich the alert before PagerDuty sees it. Use alert.eventId as the dedup_key there, and turn Include resolve notifications on so the incident resolves.

Jira Service Management

Create a Jira Service Management channel for Jira Service Management Operations, the successor to Opsgenie. You paste the API key of an API integration, and Fleetera opens, acknowledges and closes the alert itself.

See Jira Service Management for the full walkthrough.

Test with webhook.site

Before wiring a real destination, the quickest way to see exactly what Fleetera sends — headers and body — is a request-inspection service such as webhook.site. Combined with the channel test-send, this confirms the full path end to end.

Get a temporary inspection URL

Open webhook.site and copy the unique URL it gives you. It is a public HTTPS endpoint that records every request it receives.

Create a webhook channel pointing at it

Create a Fleetera webhook channel (see Webhook Notifications) with the webhook.site URL as the URL, and copy the secretShownOnce value from the create response.

Send a test notification

Trigger a test send for the channel. In the API this is:

POST /notification-channels/{channelId}/test

Fleetera delivers a clearly-marked synthetic alert.triggered payload — the rule is named Fleetera webhook test and the variable key is test_signal, so it is easy to tell apart from a real alert. The test payload is signed exactly like a real one, so you can exercise your signature check against it.

The response reports the outcome of the synthetic delivery:

{
  "delivered": true,
  "deliveryId": "a1b2c3d4-e5f6-4711-89ab-0123456789ab",
  "status": "sent",
  "httpStatus": 200,
  "attempts": 1,
  "error": null
}

delivered is the headline result. status is sent on success, or failed/pending if the receiver did not return a 2xx. httpStatus is the response code your endpoint returned (null on a network or transport failure), and error carries a short reason when the delivery did not succeed.

A test send is one-shot: unlike a real alert delivery, a test that fails transiently is not retried. Fix the endpoint and send another test.

Inspect the request

Switch back to webhook.site and open the request it received. Confirm the JSON body matches the Payload Reference, and that the X-Fleetera-Signature, X-Fleetera-Signature-Timestamp, X-Fleetera-Delivery, and X-Fleetera-Event headers are present. Use these to validate your signature-verification implementation before pointing the channel at your real destination.

Connecting Other Destinations

On this page