Benachrichtigungskanal aktualisieren
Aktualisiert einen Benachrichtigungskanal.
PATCH /api/notification-channels/:id
Die Config wird mit den bestehenden Geheimnissen zusammengeführt (merged), wobei verschlüsselte Felder, die nicht übergeben werden, erhalten bleiben, solange der Kanal seinen type behält.
Ein Wechsel des type verhält sich anders: Die gespeicherte Config gehört zum alten Kanaltyp, sie wird komplett verworfen und die Config wird aus der config dieser Anfrage neu aufgebaut. Ein Typwechsel braucht deshalb zwingend config (sonst 400), und Geheimnisse des alten Typs werden nicht übernommen.
Anfrage (Request Body) (alle optional)
| Feld | Typ | Beschreibung |
|---|---|---|
type | string | Kanaltyp, einer der unterstützten Typen. Erfordert config. |
name | string | Anzeigename, 1 bis 100 Zeichen |
config | object|string | Mit bestehenden Geheimnissen zusammengeführt (gleicher Typ) oder ersetzt die Config vollständig (Typwechsel). JSON-Objekt oder JSON-String mit höchstens 20 kB. |
delaySeconds | number | Verzögerung vor dem Senden, Ganzzahl 0 bis 86400 |
conditions | object|string|null | Alert-Bedingungen, JSON-Objekt oder JSON-String mit höchstens 20 kB |
allowedPackageTypes | string[]|null | Pakettypen, auf die dieser Kanal angewendet wird, max. 50 Einträge |
isActive | boolean | 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.
Beispiel (cURL)
curl -X PATCH "$BASE_URL/api/notification-channels/1" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"name": "Updated Email Channel",
"isActive": true
}'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,namemit mehr als 100 Zeichen,configist kein JSON-Objekt,allowedPackageTypesist kein Array)400 Bad Requestmitdata.code: "configRequiredForTypeChange"wenn sichtypeändert und keineconfigmitgeschickt wird401 Unauthorizedwenn du nicht authentifiziert bist403 Forbiddenwenn du auf Kanäle außerhalb deines Scopes zugreifst404 Not foundwenn der Kanal nicht existiert
Antwort (Response)
Gibt das aktualisierte 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.