Webhook Integration

Use ilert’s webhook integration to send alert payloads to external tools, enabling custom automation and notifications.

The webhook integration in ilert allows you to send alert or incident data to any compatible third-party system. Whether it's a custom script, CI/CD tool, or internal API, this outbound integration enables flexible automation and real-time event propagation across your tech stack.

In ilert: Create a Webhook alert action

Switch to the alert sources tab and open the alert source whose alerts you want to publish via a webhook. Click on Alert actions → Create new alert action
Select Webhook as type and click Next
In the Trigger events field, select the alert events for which you want to receive a webhook call. Click on Next.
You may optionally choose to provide Conditional execution filters to further restrict when webhooks are executed based on the alert payloads. Click Next
On the last actions tab of the wizard, make sure to provide an name and URL for your webhook. Webhook events are sent as HTTP POST to the specified URL. The URL must be accessible from the internet.
Click Save to finish the setup of your webhook.

You may also provide a custom payload template at this step, but we recommend checking out the default payload first, because it usually contains everything you need and is extended automatically when we introduce new fields. You can find more information on custom templates below.

Webhook payload

The default Webhook payload is very similar to our alert API object ⇒ https://docs.ilert.com/developer-docs/rest-api/api-reference/alerts#get-alerts-id To get more information on the status or eventType fields, visit the Template variables explained section of this page.

Below is a list of the most common webhook payloads:

Payload: alert-created

{
    "id": "12797430",
    "summary": "Test alert summary",
    "details": "Some test details",
    "reportTime": "2025-10-17T10:37:51.829Z",
    "status": "PENDING",
    "eventType": "alert-created",
    "priority": "LOW",
    "alertSource": {
        "id": 2269078,
        "name": "Apache Kafka"
    },
    "timestamp": "2025-10-17T10:37:51.838605470Z",
    "eventId": "7b21f505-bd0f-49a2-bf8f-f238919b23fc",
    "correlationId": "8b21f505-bd1f-49a2-bf8f-f246519b23fc",
    "escalationPolicy": {
        "id": 2256025,
        "name": "Default escalation"
    },
    "mergeState": "NONE"
}

The correlationId field is only present if the initial trigger for this alert action (aka update on the alert) is incoming through the event API, if the operation is run through the UI this field will not be set. Further fields like alertKey, resolvedOn, mergedOn, mergedIntoId, comment, links or images will only be set if they are present on the original alert entity.

Also note that the responders array will not be populated on the initial alert-created event, first responders will appear with (the usually automatically following up) alert-escalated webhooks.

Payload: alert-acknowledged

{
    "id": "12797430",
    "summary": "Test alert summary",
    "details": "Some test details",
    "reportTime": "2025-10-17T10:37:51.829Z",
    "status": "ACCEPTED",
    "eventType": "alert-acknowledged",
    "priority": "LOW",
    "alertSource": {
        "id": 2269078,
        "name": "Apache Kafka"
    },
    "responders": [
        {
            "user": {
                "id": 2260581,
                "username": "markofrancesca",
                "firstName": "Francesca",
                "lastName": "Sala",
                "email": "[email protected]"
            },
            "status": "PENDING"
        },
        {
            "user": {
                "id": 2195123,
                "username": "chris",
                "firstName": "Christian",
                "lastName": "Fröhlingsdorf",
                "email": "[email protected]"
            },
            "status": "ACCEPTED"
        }
    ],
    "timestamp": "2025-10-17T10:45:20.081435129Z",
    "eventId": "c91875c3-a2ea-4c79-966f-bb2f2f51a86f",
    "escalationPolicy": {
        "id": 2256025,
        "name": "Default escalation"
    },
    "mergeState": "NONE"
}

Payload: alert-comment-added

{
    "id": "12797430",
    "summary": "Test alert summary",
    "details": "Some test details",
    "reportTime": "2025-10-17T10:37:51.829Z",
    "status": "ACCEPTED",
    "eventType": "alert-comment-added",
    "priority": "LOW",
    "alertSource": {
        "id": 2269078,
        "name": "Apache Kafka"
    },
    "responders": [
        {
            "user": {
                "id": 2195123,
                "username": "chris",
                "firstName": "Christian",
                "lastName": "Fröhlingsdorf",
                "email": "[email protected]"
            },
            "status": "ACCEPTED"
        },
        {
            "user": {
                "id": 2260581,
                "username": "markofrancesca",
                "firstName": "Francesca",
                "lastName": "Sala",
                "email": "[email protected]"
            },
            "status": "PENDING"
        }
    ],
    "timestamp": "2025-10-17T10:48:05.046334302Z",
    "eventId": "a7e11740-71ef-4ca3-94c8-fb6de53224a2",
    "escalationPolicy": {
        "id": 2256025,
        "name": "Default escalation"
    },
    "mergeState": "NONE",
    "comment": "hey there"
}

The actual comment content is placed in the comment field. We are only sending the latest comment that triggered this webhook, as chat conversations tend to become huge. Note: chat messages were called comments in previous versions, hence the event name. Thread replies will not appear in this webhook.

Payload: alert-resolved

{
    "id": "12797430",
    "summary": "Test alert summary",
    "details": "Some test details",
    "reportTime": "2025-10-17T10:37:51.829Z",
    "status": "RESOLVED",
    "eventType": "alert-resolved",
    "priority": "LOW",
    "alertSource": {
        "id": 2269078,
        "name": "Apache Kafka"
    },
    "responders": [
        {
            "user": {
                "id": 2195123,
                "username": "chris",
                "firstName": "Christian",
                "lastName": "Fröhlingsdorf",
                "email": "[email protected]"
            },
            "status": "ACCEPTED"
        },
        {
            "user": {
                "id": 2260581,
                "username": "markofrancesca",
                "firstName": "Francesca",
                "lastName": "Sala",
                "email": "[email protected]"
            },
            "status": "PENDING"
        }
    ],
    "timestamp": "2025-10-17T10:50:50.957412505Z",
    "eventId": "21d64df9-ae19-40d0-b0bc-ae256a1c6e2e",
    "escalationPolicy": {
        "id": 2256025,
        "name": "Default escalation"
    },
    "mergeState": "NONE",
    "resolvedOn": "2025-10-17T10:50:50Z"
}

Missing a webhook event or payload field? Reach out to us.

Custom Webhook payload / request body

In case you want to customize the HTTP POST request body of your webhook, you can simply enable the custom fields option.

Clicking into the template fields opens the template variables overlay, giving you quick access to all supported fields.

It is possible to use If/Else and Loop blocks supported by ITL; ITL functions are not allowed in alert action custom templates.

Template variables explained

Just like the ICL (conditional execution) variable access, your template has access to the full alert object and all its subfields, you can find a description of each in the variable overlay as well.

This also grants you access to original event payloads to build templates on e.g. {{ alert.customDetails.whatever.name }}

Legacy template variables explained

This is the legacy template list, that was previously supported, it will continue to work and as soon as you use one of these variable names the template variable overlay will display legacy variables. We recommend however to move to the new variable style e.g. instead of alertId -> alert.id this inlines ICL/ITL behavior across the platform and also allows you to access alert.customDetails.whatever.id original event payloads for your webhooks.

Variable key

Description

alertId

The ID of the alert

alertKey

ID used to identify the initial event that created the alert

alertDetails

Full alert details

alertSummary

Alert summary

alertStatus

PENDING, ACCEPTED or RESOLVED

alertPriority

HIGH or LOW

alertUrl

URL that links to the alert in ilert

alertSourceId

The ID of the alert's alert source

alertSourceName

The name of the alert's alert source

escalationPolicyId

The ID of the escalation policy of the alert's alert source

escalationPolicyName

The name of the escalation policy of the alert's alert source

reportTime

ISO-8601 representation of the alert report time

link

If present, the first link in the alert's payload e.g. links to the origin monitoring tool that send the event initially

eventType

alert-created, alert-assigned, alert-auto-escalated, alert-auto-resolved, alert-acknowledged, alert-rejected, alert-raised, alert-comment-added, alert-resolved

responderNames

comma separated list of responder full names

responderEmails

comma separated list of responder emails

responderIds

comma separated list of responder user ids

FAQ

Do you support authentication?

Yes, HTTP Basic Auth is supported. The username and password must be specified in the URL.

Example: https: // username: [email protected] / webhooks / ilert

Special characters in the user name or password must be encoded URL.

If you are looking to provide custom headers, please contact us - we are collecting feature request for this.

Can you also specify the HTTP port?

Yes. By default, port 80 is used for HTTP connections and port 443 for HTTPS connections. You can overwrite the port number by adding a colon : after the host address and the port.

incident-created, incident-assigned, incident-auto-escalated, incident-auto-resolved, incident-acknowledged, incident-rejected, incident-raised, incident-comment-added, incident-resolved

Example: https://example.com:8443/webhooks/ilert

I cannot rely on user-agent headers for my firewall, is there a way to whitelist IP addresses of the webhooks?

Basically, it is not possible to whitelist the IP addresses for all of our agents, as there are just too many blocks that may change at any time. However, we do offer static IP agents in our Scale plan – the static IP addresses are listed here.

PreviousTOPdesk Outbound Integration NextZammad Outbound Integration

Last updated 3 days ago

Was this helpful?