---
title: "Webhook requests"
description: "The HTTP request Alert Management sends to a webhook endpoint, its headers, every JSON field, and what your endpoint must do."
content_type: "concept"
product: "alerts"
platform: "TIR"
url: "/tir/alerts/concepts/webhook-requests/"
---

# Webhook requests

A webhook monitoring integration sends an HTTP POST request to your endpoint each time an alert
fires or is resolved. Use it to start automated workflows in other tools as alerts happen. You set
the URL and headers in [Create a monitoring
integration](/tir/alerts/how-to/create-a-monitoring-integration/#create-a-webhook-integration). The
body has the same structure for every event. The values in the example are sample data.

## Request

| Part            | Value                                                                                         |
| --------------- | --------------------------------------------------------------------------------------------- |
| Method          | POST.                                                                                         |
| `Content-Type`  | `application/json`, sent with every request.                                                  |
| `Authorization` | Optional. Add it as a custom header, for example `Bearer <token>`, if your endpoint needs it. |
| Custom headers  | Optional. You can add up to 10 key and value pairs to an integration.                         |

## Body

```json
{
  "version": "v1",
  "monitoring_group_id": 0,
  "status": "firing",
  "alert": {
    "id": 0,
    "name": "Sample Alert",
    "resource_type": "notebook",
    "resource_type_display": "Instance",
    "metric_type": "cpu",
    "metric_type_display": "CPU Utilization",
    "operator": ">",
    "operator_display": "Greater Than",
    "threshold_value": 80,
    "severity": "Warning"
  },
  "project": {
    "id": 0,
    "name": "Sample Project",
    "location": "sample-location"
  },
  "affected_resources": [
    {
      "id": 0,
      "name": "sample-resource",
      "replica": "sample-replica",
      "gpu_uuid": "GPU-SAMPLE"
    }
  ]
}
```

The fields `resource_type_display`, `metric_type_display`, and `operator_display` hold the names the
portal shows, such as `CPU Utilization` for the metric. The sample that **Test URL** sends has the
same structure but leaves out these three fields.

## Fields

### Top level

| Field                 | Type    | Meaning                                                       |
| --------------------- | ------- | ------------------------------------------------------------- |
| `version`             | string  | Version of the body format. The current value is `v1`.        |
| `monitoring_group_id` | integer | The ID of the monitoring integration that sends this request. |
| `status`              | string  | `firing` or `resolved`.                                       |

### The `alert` object

| Field                   | Type    | Meaning                                                                                            |
| ----------------------- | ------- | -------------------------------------------------------------------------------------------------- |
| `id`                    | integer | The alert's ID.                                                                                    |
| `name`                  | string  | The alert's name.                                                                                  |
| `resource_type`         | string  | The kind of resource, such as `notebook` for an Instance or `gateway_service` for a Load Balancer. |
| `resource_type_display` | string  | The same, as the portal names it.                                                                  |
| `metric_type`           | string  | The metric, such as `cpu`.                                                                         |
| `metric_type_display`   | string  | The metric as the portal names it.                                                                 |
| `operator`              | string  | One of `>`, `<`, `>=`, `<=`, `==`, `!=`.                                                           |
| `operator_display`      | string  | The operator as the portal names it.                                                               |
| `threshold_value`       | number  | The threshold.                                                                                     |
| `severity`              | string  | `Critical`, `Warning`, or `Info`.                                                                  |

### The `project` object

| Field      | Type    | Meaning                  |
| ---------- | ------- | ------------------------ |
| `id`       | integer | The project's ID.        |
| `name`     | string  | The project's name.      |
| `location` | string  | The region of the alert. |

### The `affected_resources` list

Each entry is a resource the alert is about.

| Field      | Type    | Meaning                                                                                                              |
| ---------- | ------- | -------------------------------------------------------------------------------------------------------------------- |
| `id`       | integer | The resource's ID.                                                                                                   |
| `name`     | string  | The resource's name.                                                                                                 |
| `replica`  | string  | The replica the alert is about, for Inference and training services. Empty otherwise, including for a Load Balancer. |
| `gpu_uuid` | string  | The GPU's ID when the alert is about a GPU. Empty otherwise.                                                         |

When one resource has several affected replicas or GPUs, the field lists them separated by a comma
and a space.

## What your endpoint must do

- Accept POST requests with a JSON body.
- Answer with a 2xx status, and answer quickly. TIR waits up to 10 seconds, ignores the answer, and
  sends each request once. For slow work, answer at once and process afterward.
- If you added an `Authorization` header, check it before you read the body.

A failed request is not sent again, and the portal does not list it. To check your endpoint, use
**Test URL** in the integration form, which sends a sample alert. See [Troubleshooting webhook
alerts](/tir/alerts/troubleshooting/webhooks/).