# Integrations overview

An integration connects one monitoring tool to EvoHub On-Call. It gives the tool a unique URL (or, for email, a unique address) to send alerts to, and it decides which escalation policy pages people for those alerts. This page lists every supported integration and explains how ingest works.

## Add an integration

:::steps
### Open Integrations
Go to **On-Call → Integrations** and open the **+ Add Integration** tab.
### Pick your tool
Search or browse the catalog and click the tool.
### Name it and choose a policy
Enter an **Integration Name** and choose the **Escalation Policy** that should page people for its alerts. Click **Create Integration**.
### Copy the URL into your tool
The new integration shows its **Webhook URL** (or **Inbound email address**). Open the integration and click **Show config example** for setup steps with your URL already filled in.
:::

Creating, editing and deleting integrations needs permission to write integrations (Owners, Admins and Members by default). Reading the list needs permission to read integrations, because each integration carries its key.

## The webhook URL and key

Each integration's URL looks like this:

```text
https://evohub.io/ingest/<type>?key=<integration key>
```

- `<type>` selects the parser for the tool, for example `prometheus` or `datadog`.
- The **integration key** (shown as **API Key** in the integration) identifies the integration. It decides the organization and the escalation policy; nothing in the request body can override it.
- No other authentication is needed: monitoring tools cannot sign in, so the key in the URL is the credential. Treat the URL like a password. If it leaks, delete the integration and create a new one.

The **API** integration also accepts the key in the request body or an `Authorization: Bearer` header. The **Email** integration uses an inbound email address instead of a URL.

## Manage an integration

Click an integration on the **Installed** tab to open it. You can:

- copy the **Webhook URL** and **API Key**,
- see **Total Events** and **Last Event**,
- **View this integration's alerts**,
- **Edit** its name and escalation policy,
- **Disable** it (requests are refused until you **Enable** it again), or
- **Delete** it — its URL and key stop working immediately.

An integration with no escalation policy still records alerts, but nobody is paged.

## Supported integrations

| Integration | Type in URL | How it connects | Auto-resolve | Setup |
| --- | --- | --- | --- | --- |
| **API** | `api` | Your own scripts and tools send JSON; trigger, acknowledge or resolve. | Send `event_action: resolve` with the same `dedup_key`. | [Alert API and generic webhook](https://docs-dev.evohub.io/generic-webhook.md) |
| **Prometheus** | `prometheus` | Alertmanager webhook receiver. | Yes, with `send_resolved: true`. | [Prometheus Alertmanager](https://docs-dev.evohub.io/prometheus-alertmanager.md) |
| **Grafana** | `grafana` | Grafana Alerting webhook contact point. | Yes. | [Grafana](https://docs-dev.evohub.io/grafana.md) |
| **Datadog** | `datadog` | Datadog Webhooks integration, mentioned in monitor messages. | Yes, when the monitor recovers. | [Datadog](https://docs-dev.evohub.io/datadog.md) |
| **Zabbix** | `zabbix` | Webhook media type with a short script. | Yes, with a recovery message. | [Zabbix](https://docs-dev.evohub.io/zabbix.md) |
| **PRTG** | `prtg` | "Execute HTTP Action" notification template. | Yes, when the sensor is Up again. | [PRTG](https://docs-dev.evohub.io/prtg.md) |
| **Email** | — | A unique inbound email address. | Yes, from a follow-up email that says the issue recovered. | [Email](https://docs-dev.evohub.io/email-integration.md) |
| **New Relic** | `newrelic` | Webhook destination used by an alert workflow. | Yes, when the issue is closed. | [Below](#new-relic) |
| **AWS CloudWatch** | `cloudwatch` | SNS topic with an HTTPS subscription. | Yes, with the OK action set. | [Below](#aws-cloudwatch) |
| **Azure Monitor** | `azuremonitor` | Action group webhook with the common alert schema. | Yes. | [Below](#azure-monitor) |
| **Dynatrace** | `dynatrace` | Problem notification, custom integration. | Yes. | [Below](#dynatrace) |
| **Sentry** | `sentry` | Internal integration with alert rule action. | Yes, when the issue is resolved. | [Below](#sentry) |
| **Google Cloud** | `googlecloud` | Cloud Monitoring webhook notification channel. | Yes, when the incident closes. | [Below](#google-cloud-monitoring) |
| **UptimeRobot** | `uptimerobot` | Web-Hook alert contact. | Yes, when the monitor is up. | [Below](#uptimerobot) |
| **Pingdom** | `pingdom` | Webhook integration assigned to checks. | Yes, when the check recovers. | [Below](#pingdom) |
| **Site24x7** | `site24x7` | Third-party webhook integration. | Yes, when the monitor is up. | [Below](#site24x7) |
| **Statuscake** | `statuscake` | Contact group webhook URL. | Yes, when the test is up. | [Below](#statuscake) |
| **Nagios** | `nagios` | Notification command that posts JSON with `curl`. | Yes, on a RECOVERY notification. | [Below](#nagios) |
| **Cortex XDR** | `cortex` | Cortex XDR / XSIAM webhook forwarding. | Yes, when the issue is resolved. | [Below](#cortex-xdr) |
| **OpenSearch** | `opensearch` | Alerting notification channel (custom webhook). | No — resolve in EvoHub. | [Below](#opensearch) |

Uptime monitors in EvoHub can also page On-Call directly, without an integration. See [Uptime alerts and silence windows](https://docs-dev.evohub.io/uptime-alerts-and-silence-windows.md). For chat, see [Slack](https://docs-dev.evohub.io/slack.md).

## How ingest works

When a tool sends to an integration URL (the API and Email integrations answer slightly differently; see their pages):

1. EvoHub checks the key. A missing, unknown or disabled key is refused with `401` and the code `INVALID_KEY`.
2. The parser reads the tool's payload. A body the parser cannot read is refused with `400` and `INVALID_BODY`.
3. Each firing alert in the payload opens an alert (or matches an open one, see below), and the integration's escalation policy starts.
4. Each recovery in the payload resolves the matching open alert.

The response is `200` with a count of what happened:

```json
{
  "data": { "received": 1, "created": 1, "resolved": 0 },
  "success": true
}
```

EvoHub answers `200` whenever the payload was read, even if it produced no alert, so that tools do not disable the webhook after repeated errors. If the key could not be checked on EvoHub's side, the answer is `503` with `INGEST_UNAVAILABLE` and a `Retry-After` header; most tools retry automatically.

### Deduplication

Every alert gets a **fingerprint** from the tool's own identifiers — Alertmanager's fingerprint, a Datadog alert ID, a Zabbix host and trigger, a PRTG sensor ID, and so on. If an alert arrives while an alert with the same fingerprint is still open (triggered or acknowledged), EvoHub records **Retriggered** on the existing alert instead of opening a new one, and nobody is paged again. After the alert is resolved, the next one with that fingerprint opens a new alert. Only new alerts count toward usage; retriggers do not.

### Auto-resolve

When a tool reports that a problem has recovered, EvoHub resolves the open alert with the same fingerprint, and the escalation stops. The alert's timeline shows it was resolved by the integration. If the tool's recovery notification is not configured, alerts stay open until someone resolves them.

### Severity

Each parser maps the tool's severity to EvoHub's **critical**, **high**, **medium**, **low** or **info**. The integration pages describe the mapping. When a tool sends no severity EvoHub recognizes, most parsers use **medium**; email alerts are always **high**.

## Other integrations

These steps match the **Show config example** text in the console, where your URL is filled in for you. Replace `YOUR_URL` with the integration's **Webhook URL**.

### New Relic

1. In New Relic, go to **Alerts → Destinations** and add a **Webhook** with **Endpoint URL** `YOUR_URL`.
2. Go to **Alerts → Workflows**, create a workflow and notify through that webhook.

New Relic's default payload template works as-is. Alerts resolve when the issue is closed or deactivated.

### AWS CloudWatch

1. Create an SNS topic and set it as the alarm's **In alarm** action and its **OK** action (the OK action enables auto-resolve).
2. Add a subscription to the topic with **Protocol** HTTPS and **Endpoint** `YOUR_URL`. Leave **Raw message delivery** off.
3. EvoHub confirms the subscription automatically. Check in SNS that it shows an ARN rather than *PendingConfirmation*.

### Azure Monitor

1. In Azure Monitor, go to **Alerts → Action groups** and create or edit one.
2. Add an action of type **Webhook** with **URI** `YOUR_URL` and **Enable common alert schema** set to **Yes**. Payloads without the common alert schema are refused.
3. Attach the action group to your alert rules.

### Dynatrace

1. In Dynatrace, go to **Settings → Integration → Problem notifications → Add notification → Custom integration**.
2. Set **Webhook URL** to `YOUR_URL` and leave the pre-filled custom payload as it is.
3. Optionally add `"ProblemSeverity": "{ProblemSeverity}"` and `"ProblemDetailsText": "{ProblemDetailsText}"` to the payload for better severity mapping and a fuller description.

### Sentry

1. In Sentry, go to **Settings → Developer Settings → Custom Integrations** and create a new **Internal** integration.
2. Set **Webhook URL** to `YOUR_URL`, enable **Alert Rule Action**, and under **Webhooks** check **issue**.
3. In your alert rule, add the action that sends a notification through your integration.

The legacy Sentry "Webhooks" plugin is not supported.

### Google Cloud Monitoring

1. In Google Cloud, go to **Monitoring → Alerting → Edit notification channels → Webhooks → Add new** and set **Endpoint URL** to `YOUR_URL`.
2. Select this channel in your alerting policies.

An incident opening creates an alert; the incident closing resolves it.

### UptimeRobot

1. In UptimeRobot, go to **My Settings → Alert Contacts → Add → Web-Hook**.
2. In **URL to Notify**, paste `YOUR_URL&` — including the `&` at the end. UptimeRobot appends its alert data to the URL, and without the `&` the key is corrupted and nothing arrives.
3. No POST value is needed.

### Pingdom

1. In My Pingdom, go to **Integrations → Add integration**, choose **Webhook** and set **URL** to `YOUR_URL`.
2. Edit each check, open **Connect integrations** and enable the webhook. It sends nothing until it is assigned to a check.

### Site24x7

1. In Site24x7, go to **Admin → Third-Party Integration → Webhook**.
2. Set **Hook URL** to `YOUR_URL`, **Method** POST, turn on **Send Incident Parameters**, and turn on **Post as JSON** (recommended; form mode also works).

### Statuscake

1. In StatusCake, go to **Contact Groups**, create or edit one and set **Web Hook URL** to `YOUR_URL`.
2. Assign the contact group to your uptime tests.

StatusCake sends a fixed form post on Down and Up; there is nothing else to configure.

### Nagios

1. Add a notification command to `commands.cfg` (the `$…$` parts are Nagios macros):

   ```text
   define command {
     command_name  notify-evohub
     command_line  /usr/bin/curl -s -X POST "YOUR_URL" -H "Content-Type: application/json" -d '{"host":"$HOSTNAME$","service":"$SERVICEDESC$","state":"$SERVICESTATE$","notification_type":"$NOTIFICATIONTYPE$","output":"$SERVICEOUTPUT$"}'
   }
   ```

2. Set `notify-evohub` as the `service_notification_commands` of the contact your services notify.

For host alerts, use `$HOSTSTATE$` and `$HOSTOUTPUT$` and leave `service` empty. If check output may contain quotes, use a small wrapper script that JSON-escapes it.

### Cortex XDR

Requires Cortex XDR 5.x or later, or XSIAM 3.x or later.

1. Go to **Settings → Configurations → Integrations → External Applications → Add Application → Webhook** and set **URL** to `YOUR_URL`.
2. Go to **Settings → Configurations → General → Notifications**, add a **Forwarding Configuration** and pick the issues to forward.

Cortex sends its own issue JSON, which EvoHub reads natively.

### OpenSearch

1. In OpenSearch, go to **Notifications → Channels → Create channel**, choose **Custom webhook**, set **Define endpoint by** to **Webhook URL** and paste `YOUR_URL`. (In "Custom attributes URL" mode, the `?key=` part is dropped.)
2. The default action message works as-is. For richer fields, replace the monitor trigger's action message with:

   ```json
   {
     "monitor": "{{ctx.monitor.name}}",
     "trigger": "{{ctx.trigger.name}}",
     "severity": "{{ctx.trigger.severity}}",
     "message": "{{ctx.trigger.name}}",
     "period_start": "{{ctx.periodStart}}",
     "period_end": "{{ctx.periodEnd}}"
   }
   ```

The channel's **Send test message** creates a real test alert, so the whole path, paging included, is exercised. OpenSearch sends no recovery notification; resolve these alerts in EvoHub.

## Related

- [Alert API and generic webhook](https://docs-dev.evohub.io/generic-webhook.md)
- [Escalation policies](https://docs-dev.evohub.io/escalation-policies.md)
- [Alerts and incidents](https://docs-dev.evohub.io/alerts-and-incidents.md)
- [Migrate from Opsgenie](https://docs-dev.evohub.io/migrate-from-opsgenie.md)