---
title: "Events Ingest"
description: "Öffentlicher Alert-Ingest-Endpunkt für Incident Management. Beliebiges JSON-Alert-Payload aus deinem eigenen Monitoring- oder Alerting-System senden; es wird asynchron zu einem Incident verarbeitet."
---

`POST /api/im/events`

Nimmt ein beliebiges JSON-Alert-Payload aus deinem eigenen Monitoring- oder Alerting-System entgegen und stellt es zur asynchronen Verarbeitung in Incident Management in die Queue. Dies ist der primäre Integrations-Endpunkt, um Alerts aus Drittsystemen einzuspeisen.

## Authentifizierung

Erfordert einen **organisationsweiten** API-Token (`Authorization: Bearer wsm_...`, erstellt ohne `customerId`, siehe [Organisations-Token erstellen](/de/api/api-tokens/create-organization-token)). Ein kunden-gescopter Token wird mit `403 Forbidden` (`imAccessDenied`) abgelehnt. Incident Management muss außerdem für die Organisation aktiviert sein, sonst wird die Anfrage mit `403 Forbidden` (`imNotEnabled`) abgelehnt.

## Rate Limit

600 Anfragen pro Minute pro Organisation, nicht pro IP. Ein Monitoring-System, das über viele Quell-IPs verteilt sendet, teilt sich ein Kontingent mit seiner Organisation.

## Anfrage (Request Body)

Ein beliebiges JSON-Objekt. Das Payload wird gegen eine `api`-Alert-Source gespeichert, die beim ersten Aufruf dieses Endpunkts automatisch für deine Organisation angelegt wird, und anhand des Feld-Mappings dieser Source in einen Alert überführt. Es gibt kein festes Request-Schema. Sende, was dein Alerting-System liefert.

Limits, die vor dem Einreihen in die Queue geprüft werden:

| Limit | Wert | Fehler |
|-------|-------|---------|
| Body-Größe | 256 KB | `413 Payload Too Large` (`payloadTooLarge`) |
| JSON-Verschachtelungstiefe | 20 Ebenen | `422 Payload too deep` (`payloadTooDeep`) |
| Body muss gültiges JSON sein | — | `422 Invalid JSON` (`invalidJson`) |

Ein leerer Request-Body wird als `{}` behandelt.

## Beispiel (cURL)

```bash
curl -X POST "$BASE_URL/api/im/events" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Database connection pool exhausted",
    "severity": "critical",
    "host": "db-primary-01"
  }'
```

## Antwort (Response)

`202 Accepted`: der Alert wurde eingereiht, aber noch nicht verarbeitet. Es gibt keine synchrone Incident- oder Alert-ID in der Antwort.

```json
{
  "accepted": true
}
```

## Häufige Fehler

- `401 Unauthorized` wenn du nicht authentifiziert bist
- `403 Forbidden` (`imAccessDenied`) bei Verwendung eines kunden-gescopten Tokens, oder wenn deine Session keine IM-berechtigte Rolle hat
- `403 Forbidden` (`imNotEnabled`) wenn Incident Management für die Organisation nicht aktiviert ist
- `413 Payload Too Large` (`payloadTooLarge`) wenn der Body 256 KB überschreitet
- `422 Invalid JSON` (`invalidJson`) wenn der Body kein gültiges JSON ist
- `422 Payload too deep` (`payloadTooDeep`) wenn das geparste JSON mehr als 20 Ebenen verschachtelt ist
- `429 Too Many Requests` wenn deine Organisation 600 Anfragen/Minute überschreitet (siehe `retryAfter` im Antwort-Body)
- `503 Service Unavailable` (`unavailable`) wenn der Alert nicht eingereiht werden konnte, sicher wiederholbar