Connecting Slack, Teams & PagerDuty
Wire Fleetera webhook notifications into common destinations and test your endpoint.
Fleetera sends a structured, signed JSON payload (see the Payload Reference) — not a message pre-formatted for any particular chat or incident tool. Some destinations accept arbitrary JSON directly; others expect a specific body shape, so you place a small transformer between Fleetera and the destination to reshape the payload.
This page covers the common destinations and a quick way to test any endpoint.
Whatever destination you choose, verify the HMAC signature at the point that first receives the request — your transformer, relay, or workflow — before forwarding the alert onward.
Slack
A classic Slack Incoming Webhook expects a body shaped like {"text": "..."} (or Slack Block Kit). Fleetera's payload is not in that shape, so you cannot point a webhook channel directly at a classic Slack Incoming Webhook URL and expect a readable message — Slack will reject or ignore the unexpected body.
You have two accurate options:
- A small relay/transformer. Point the Fleetera channel at a tiny service you control (for example, a serverless function). It verifies the signature, builds a Slack message such as
{"text": "🔴 Gearbox over-temp on asset … (87.4 degC > 80)"}, and POSTs that to your Slack Incoming Webhook URL. - A Slack Workflow webhook. Create a Slack Workflow with a "Webhook" starting step. A Workflow webhook accepts a JSON body with the variables you declare, so you can map fields from Fleetera's payload into the workflow and then post a formatted message. This avoids running your own relay, but you still map the payload to the workflow's expected variables.
In both cases, put the receiving URL (your relay, or the Workflow webhook) in the Fleetera channel's URL, and add any auth header your receiver needs under Headers.
Microsoft Teams
Send Fleetera alerts to Teams using Workflows (Power Automate), which replaces the older Office 365 connector webhooks.
Create a workflow from the Teams template
In Teams, create a new Workflow using the "Post to a channel when a webhook request is received" template (the trigger is "When a Teams webhook request is received"). This generates an HTTPS URL that accepts an incoming HTTP request.
Point the Fleetera channel at the workflow URL
Create a Fleetera webhook channel with the workflow's URL as the URL. Fleetera will POST its JSON payload to the workflow on each alert.
Map the payload into an Adaptive Card
In the workflow, parse the incoming JSON and build the Teams message — typically an Adaptive Card — from the payload fields (alert.rule.name, alert.severity, alert.triggerValue, alert.labels.assetId, and so on). Add the signature-verification step before you post, using the channel secret.
PagerDuty
PagerDuty's Events API v2 expects its own event shape (a routing_key, an event_action of trigger or resolve, and a payload block). Map Fleetera's payload to it with a transformer:
- A transformer you host. Point the Fleetera channel at a small service that verifies the signature, then translates the Fleetera payload into a PagerDuty Events API v2 event and POSTs it to
https://events.pagerduty.com/v2/enqueuewith your integration routing key. - PagerDuty's Custom Event Transformer (CET). Create a Custom Event Transformer integration on a PagerDuty service. It gives you an inbound URL (tied to a routing key) and runs a small script that turns an arbitrary inbound payload into a PagerDuty event. Put the CET URL in the Fleetera channel.
A natural mapping is:
- Fleetera
type: "alert.triggered"→ PagerDutyevent_action: "trigger";alert.resolved→resolve. - Use the Fleetera
id(the delivery ID) oralert.eventIdto derive PagerDuty'sdedup_key, so a trigger and its resolve correlate to the same incident. Enable resolved notifications on the channel so PagerDuty receives the resolve. - Map
alert.severityto the PagerDutypayload.severity, andalert.rule.nameplus the labels into the PagerDutysummaryandcustom_details.
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}/testFleetera 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.