Webhook Destination Configuration

Overview

Configure Rootly webhook authentication in Xyte using Rootly's supported query string secret format.

If the secret is sent in an unsupported format, the webhook shows an Error status and delivery fails.

Correct configuration

Pass the secret as a query string parameter at the end of the URL, not as a header.

Supported endpoint formats

Rootly documents two valid endpoint patterns:

Both formats support the ?secret=<value> query parameter for authentication.

Common misconfiguration

Do not use the custom header to pass the secret. Use the custom header only for Content-Type: application/json.

URL examples

Base endpoint:

https://webhooks.rootly.com/webhooks/incoming/generic_webhooks?secret=abcd

Notify endpoint:

https://webhooks.rootly.com/webhooks/incoming/generic_webhooks/notify/Group/<group_id>?secret=abcd

Additional resources

• Generic Webhook Alert Source — Overview
• Generic Webhook Alert Source — Installation

Before you start: which SolarWinds do you have?

"SolarWinds" covers several products, and they connect to Xyte in opposite directions.

Self-hosted SolarWinds has no inbound webhook receiver, and Xyte does not send webhooks to private network addresses.

Part 1 — Generate the incoming webhook URL in SolarWinds

1. Sign in to SolarWinds Incident Response:
   • US region — https://incidents.na-01.cloud.solarwinds.com
   • EU region — https://incidents.eu-01.cloud.solarwinds.com
2. In the left sidebar, open Services.
3. Open the service that should receive Xyte alerts, or create one with ADD NEW SERVICE.
4. On the service page, click ADD ALERT SOURCE. If the service already has alert sources, use ADD in the Alert Sources card instead.

5. In the search box, type webhook and select Incident Webhook.

⚠️

Do not pick the Solarwinds Webhook card. That alert source ingests alerts from SolarWinds Orion into Incident Response and is unrelated to Xyte. The card you want is Incident Webhook.

6. A panel opens on the right showing a generated Webhook URL:

https://api.squadcast.com/v2/incidents/api/<your-unique-token>

7. Click ADD ALERT SOURCE, then SAVE ALL.
8. Use the COPY button next to the Webhook URL — you need it for Part 2.

🔐

The URL contains your token. Treat it as a secret: anyone holding it can raise alerts in your SolarWinds account.

Part 2 — Use the URL in Xyte

1. In the Xyte organization portal, go to Connections › Integrations.
2. Open the Webhooks tab, then select Webhook.
3. Paste the SolarWinds URL into all three fields:
   • Create incident URL
   • Update incident URL
   • Close incident URL
4. (Optional) Tick Add custom header to requests and set:

5. (Optional) Under Filter incidents by priority, set the minimum priority to report, so only incidents at or above that priority reach SolarWinds.
6. Click Update. The integration status changes to Active.
7. Click Test create, Test update and Test close. Each should show Test connection successful.

Part 3 — Verify

In SolarWinds, open Incidents. Within a few seconds you should see new entries whose Alert Source is Incident Webhook, on the service you configured.

You can also confirm from the service page itself: the Alert Sources card lists Incident Webhook with a running count under OPEN INCIDENTS.

Known limitations

• Alerts arrive unnamed. They appear as Generic Webhook Alert rather than the device or incident name. SolarWinds reads a message field; Xyte sends title, and the webhook body cannot be re-mapped.
• Closing an incident in Xyte does not resolve it in SolarWinds. A close sends another event that SolarWinds records as a new Triggered alert. SolarWinds expects trigger / resolve.

The practical effect is that the SolarWinds queue grows and does not clear itself, so do not rely on it for incident lifecycle. Either resolve alerts in SolarWinds manually, or route the Xyte webhook through an automation tool that rewrites the body before forwarding it.

What Xyte sends

{
  "change": "create",
  "location": "HQ > Floor 2 > Room 210",
  "device": "Meeting Room Display",
  "id": "ec185c0b-dc6c-46a4-ab0f-b75fdfd9c5ee",
  "short_id": "INC-E6Q9D",
  "title": "Device issue: Meeting Room Display",
  "status": "active",
  "priority": 3,
  "description": "Device stopped reporting",
  "issue": "device_offline",
  "created_at": "2026-08-31T08:03:34.247Z",
  "updated_at": "2026-08-31T08:03:34.247Z"
}

change is create, update or close. space_id is included when the space has a custom ID.

Requirements for any webhook destination

• The URL must use https. Plain http is rejected.
• The destination must be reachable on the public internet. Private, loopback and link-local addresses are rejected, including hostnames that resolve to an internal address.
• The body is fixed — fields cannot be renamed or re-mapped. One extra key/value pair can be added with the custom parameter option.
• Only one custom header is sent. Destinations requiring two or more — such as SolarWinds Service Desk, which needs both an authorization header and an Accept version header — cannot be used directly and need a relay.

Self-hosted SolarWinds — poll Xyte instead

In Xyte, copy your organization API key from Settings. Then in SolarWinds go to Settings › All Settings › Manage API Pollers › New and configure:

Click Send request, then use Stored Values to select the fields SolarWinds should monitor. Assign the poller to a node and set a polling interval.

Supported query parameters: status (active / closed), priority (critical / high / moderate / low / planning), from and to (unix time), page, per_page.

📘

API Pollers monitor selected values from the response, so they suit counts and statuses better than full incident text.