Benachrichtigungskanal erstellen
Erstellt einen neuen Benachrichtigungskanal. Geheimnisse in config werden serverseitig verschlüsselt.
POST /api/notification-channels
Anfrage (Request Body)
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
type | string | Ja | - | Kanaltyp, einer aus der Liste unten (alles andere ist ein 400) |
name | string | Ja | - | Anzeigename, 1 bis 100 Zeichen |
config | object|string | Ja | - | Kanalkonfiguration (siehe Typtabelle). Als JSON-Objekt oder JSON-String mit höchstens 20 kB übergeben. |
organizationId | number | Nein | aus Session | Organisations-Scope |
customerId | number | Nein | null | Kunden-Scope |
websiteId | number | Nein | null | Website-Scope. Erfordert sourceChannelId. |
sourceChannelId | number|string | Bedingt | null | Übergeordnete Kanal-ID für Website-Overrides |
category | string | Nein | direct | direct oder integration |
delaySeconds | number | Nein | 0 | Verzögerung vor dem Senden des Alerts, Ganzzahl 0 bis 86400 |
conditions | object|string | Nein | null | Alert-Bedingungen (z. B. {"onlyFullService": true, "minIncidentDuration": 300}), JSON-Objekt oder JSON-String mit höchstens 20 kB |
isActive | boolean | Nein | true | Ob der Kanal aktiv ist |
delaySeconds läuft für diesen Kanal auf einer eigenen Uhr, beginnend in dem Moment, in dem
dieser Kanal benachrichtigen würde, unabhängig von jedem anderen Kanal am selben Alarm. Beginnt
in dieser Zeit ein Wartungsfenster oder ist die Störung bis dahin bereits behoben, wird auf
diesem Kanal nichts mehr zugestellt.
priority ist aus der Kanalkonfiguration entfernt. Eine Anfrage, die das Feld noch mitschickt,
wird weiterhin angenommen, das Feld wird einfach ignoriert, sodass bestehende Integrationen
unverändert weiterlaufen.
Kanaltypen
Direkt (category: "direct"): email, sms, webhook.
Integrationen (category: "integration"): incident_management, slack, discord, teams, pagerduty, opsgenie, allquiet, telegram, googlechat, mattermost, rocketchat, matrix, lark, dingtalk, wecom, ilert, grafanaoncall, squadcast, incidentio, pushover, ntfy, gotify, jira, github, gitlab, linear, servicenow.
Die config-Felder hängen vom Typ ab: siehe Integrationen, was jeder Kanal benötigt. Du kannst einen Kanal vor dem Speichern mit dem Endpunkt Benachrichtigungskanal testen validieren.
incident_management
Uptimeifys eigenes Incident Management ist ein Integrationskanal wie jeder andere, mit zwei Unterschieden:
- Er erwartet eine leere
config({}). Es gibt keinen Endpunkt und keine Zugangsdaten; bestätigte Ausfälle werden intern zugestellt. - Er ist nicht testbar: der Endpunkt Benachrichtigungskanal testen unterstützt diesen Typ nicht.
Der Kanal steuert, welche Monitore über Incident Management alarmieren. Sein Geltungsbereich (customerId / websiteId, beide optional, beide weglassen für die gesamte Organisation) und seine allowedPackageTypes bestimmen, wessen bestätigte Ausfälle zu IM-Incidents werden; alles andere bleibt bei den klassischen Benachrichtigungen. Ein Monitoring-Ausfall erreicht Incident Management nur dann, wenn ein passender, aktiver Kanal existiert und das Paket des Kunden Integrations-Alarme erlaubt.
Beispiel (cURL): E-Mail-Kanal
curl -X POST "$BASE_URL/api/notification-channels" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"type": "email",
"name": "Ops Email",
"config": { "email": "ops@deinkunde.com", "to": "Ops Team <ops@deinkunde.com>" },
"organizationId": 1
}'Beispiel (cURL): Slack-Kanal
curl -X POST "$BASE_URL/api/notification-channels" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"type": "slack",
"name": "Alerts Slack Channel",
"config": { "webhookUrl": "https://hooks.slack.com/services/T00/B00/xxx" },
"organizationId": 1
}'Beispiel (cURL): Webhook-Kanal
curl -X POST "$BASE_URL/api/notification-channels" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"type": "webhook",
"name": "Custom Webhook",
"config": {
"url": "https://deinkunde.com/webhook",
"method": "POST",
"headers": { "X-Custom-Header": "value" },
"bodyTemplate": "{\"text\": \"{{websiteName}} is {{status}}\"}",
"timeout": 30,
"retryAttempts": 3,
"retryDelay": 60,
"expectedStatusCodes": "200,201,204"
},
"organizationId": 1
}'Häufige Fehler
400 Bad Requestmitdata.codeinvalidRequestBody, wenn einemail- odersms-Kanal einen Empfänger trägt, den der Zustellweg nie annehmen könnte. Geprüft werden beitype: emaildie Schlüsselconfig.toundconfig.email, beitype: smsdie Schlüsselconfig.to,config.phoneNumbersundconfig.phoneNumber; eine kommagetrennte Zeichenkette und ein Array gelten beide als Liste, jeder Eintrag wird geprüft, und die Meldung nennt den ersten beanstandeten Wert. Eine Mailadresse braucht genau ein@mit Inhalt auf beiden Seiten und ohne Leerzeichen, die FormName <adresse>ist erlaubt; eine SMS-Nummer muss E.164 sein: ein+, eine Ziffer 1-9, dann 7 bis 14 weitere Ziffern, ohne Leerzeichen, Bindestriche oder Klammern. Das sind die Regeln des Zustellwegs selbst, ein hier abgewiesener Wert hätte also nie einen Alarm empfangen. Ein Kanal OHNE eigenen Empfänger bleibt gültig: die Zustellung fällt dann auf die hinterlegte Adresse des Kunden oder der Organisation zurück. Geprüft werden nuremailundsms; bei jedem anderen Typ bedeuten diese Schlüssel etwas anderes.400 Bad Requestmitdata.codeinvalidRequestBody, wenn eine Ziel-URL inconfigkeine parsebarehttp/https-URL ist oder auf eine private, Loopback- oder Link-Local-Adresse, auflocalhost, auf einen reservierten Privatnamen (.local,.internal,.home.arpa) oder auf einen Hostnamen ohne Punkt zeigt. Als Ziel-URL gilt jede Zeichenkette der oberstenconfig-Ebene, die mithttp://oderhttps://beginnt; Felder mit Nachrichteninhalt (bodyTemplate,webhookBodyTemplate,headers) sind ausgenommen, ein Link ins eigene Netz ist dort berechtigt. Die Prüfung löst kein DNS auf; ein öffentlicher Name, der erst später privat auflöst, wird stattdessen bei der Zustellung gestoppt.400 Bad Requestwenn der Body die Validierung nicht besteht: unbekanntertype,namefehlt oder hat mehr als 100 Zeichen,configoderconditionsist kein JSON-Objekt (oder ein String, der sich nicht zu einem parsen lässt),delaySecondsaußerhalb des Bereichs401 Unauthorizedwenn du nicht authentifiziert bist403 Forbiddenwenn du Kanäle für eine Organisation erstellst, für die du keine Schreibrechte hast409 Conflictwenn bereits ein doppelter Website-Override existiert409 Conflictmitdata.codenotificationChannelRecipientExists, wenn im selben Geltungsbereich bereits ein AKTIVER Kanal desselben Typs an dieselbe Adresse zustellt. Die Antwort nennt den vorhandenen Kanal indata.channelId. Ein wiederholter Anlege-Aufruf, dessen Antwort nie ankam, bekommt damit diesen Fehler statt eines zweiten Kanals; ein deaktivierter Kanal blockiert nie, und geprüft wird nicht der Name, sondern die Adresse.
Antwort (Response)
Gibt das erstellte Benachrichtigungskanal-Objekt zurück. Siehe Fehlercodes für Fehlerantworten.
Berechtigungen
Organisations-Admins schreiben Kanäle auf jeder Ebene. Ein kundengebundener Zugang (Rolle
readonly) darf Kanäle anlegen, ändern und löschen, die an einen SEINER EIGENEN Kunden gebunden
sind. Genau das bietet ihm die Integrationsseite im Dashboard an, während die API es bis zum
04.09.2026 mit einem nackten 403 verweigert hat.
Zwei Grenzen bleiben: Ein Kanal auf Organisationsebene, also ohne customerId, ist weiterhin
Admins vorbehalten, und ein Kanal eines Kunden ausserhalb des eigenen Scopes wird abgelehnt wie
bisher. Die Rollen editor und responder schreiben hier nicht.
Benachrichtigungskanäle
Verwalte, wie und wohin Alerts zugestellt werden. Kanäle können auf Organisationsebene (Standard für alle Kunden), auf Kundenebene (Override für einen bestimmten Kunden) oder auf Website-Ebene (Override für einen bestimmten Monitor) liegen.
Benachrichtigungskanal löschen
Löscht einen Benachrichtigungskanal. War der Kanal ein Standard auf Organisationsebene, werden die Organisations-Standards automatisch synchronisiert.