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 (vollständige Liste unten)
`name`	string	Ja	-	Anzeigename
`config`	object\|string	Ja	-	Kanalkonfiguration (siehe Typtabelle). Als JSON-Objekt oder JSON-String ü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`
`priority`	number	Nein	1	Niedriger = höhere Priorität
`delaySeconds`	number	Nein	0	Verzögerung vor dem Senden des Alerts
`conditions`	object\|string	Nein	null	Alert-Bedingungen (z. B. `{"onlyFullService": true, "minIncidentDuration": 300}`)
`isActive`	boolean	Nein	true	Ob der Kanal aktiv ist

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" },
    "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": { "secret": "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

401 Unauthorized wenn du nicht authentifiziert bist
403 Forbidden wenn du Kanäle für eine Organisation erstellst, für die du keine Schreibrechte hast
409 Conflict wenn bereits ein doppelter Website-Override existiert

Antwort (Response)

Gibt das erstellte Benachrichtigungskanal-Objekt zurück. Siehe Fehlercodes für Fehlerantworten.

Benachrichtigungskanal erstellen

Auf dieser Seite