# Uptimeify Dokumentation – Vollständiger Export
> Erweiterter, textbasierter Export der Uptimeify-Dokumentation mit Seiteninhalten.

Compact index: https://docs.uptimeify.io/de/llms.txt

## Overview

### Willkommen bei Uptimeify
URL: https://docs.uptimeify.io/de
Description: White-Label Uptime-, SSL- & synthetisches Monitoring für Agenturen — gehostet in der EU.
Summary: Uptimeify ist eine **White-Label-Monitoring-Plattform für Agenturen und MSPs**. Überwache die Websites und Infrastruktur deiner Kunden, alarmiere die richtigen Leute in dem Moment, in dem etwas ausfällt, und gib jedem Kunden eine gebrandete Status-Seite plus automatischen Bericht — alles unter deiner eigenen Marke, gehostet in der EU. ## Was du überwachen kannst Aus einem einzigen Dashboard: - **Websites** — Uptime, SSL-Zertifikat, Antwortzeit, Keyword-Präsenz, Seitengröße und HTTPS-Weiterleitungs-Checks. - **Server & Dienste** — DNS, ICMP (Ping), SSH, FTP, SMTP, IMAP/POP, DNSBL-Blacklist- und Domain-Ablauf-Checks. - **Synthetisch & geplant** — mehrstufige Browser-Flows mit Playwright und Heartbeat (Cron)-Checks für Hintergrund-Jobs. Unter [Monitoring](/de/monitoring) findest du jeden Check-Typ und wie du Intervalle, Schwellenwerte und Standorte feinjustierst. ## Alarme, die nicht ständig falsch anschlagen Jeder Fehler wird von **mehreren EU-Standorten** bestätigt, bevor ein Vorfall geöffnet wird — du wirst also bei echten Ausfällen alarmiert, nicht bei Netzwerk-Schluckaufs. Leite Alarme an **29 Benachrichtigungskanäle** (Slack, Microsoft Teams, PagerDuty, Opsgenie, SMS, E-Mail, Webhooks und mehr) mit mehrstufiger, zeitbasierter Eskalation weiter, sodass ein nicht bestätigter Alarm automatisch an den nächsten Verantwortlichen geht. Wie die Erkennung funktioniert, erfährst du unter [Vorfälle](/de/incidents); Kanäle richtest du unter [Integrationen](/de/integrations) ein. ## Kundenseitig, unter deiner Marke - **Status-Seiten** — gebrandet, öffentlich oder passwortgeschützt, auf deiner eigenen Domain. Siehe [Status-Seiten](/de/status-pages). - **Automatische PDF-Berichte** — mit deinem Logo, um wiederkehrende Gebühren zu rechtfertigen. - **Wartungsfenster** — unterdrücken Alarme bei geplanten Arbeiten. Siehe [Wartung](/de/maintenance). ## Gebaut für Agenturen Unbegrenzte Unter-Accounts pro Kunde, Margen-Kontrolle bei Care-Plänen und eine vollständige **REST-API**, um Kunden, Monitore, Status-Seiten und Benachrichtigungskanäle zu automatisieren. Starte mit der [API-Dokumentation](/de/api). ## Wähle ein Thema <Cards> <Card title="Monitoring" href="/de/monitoring"> Website-, Uptime-, SSL- und synthetische Monitore einrichten und ihre Checks feinjustieren. </Card> <Card title="Statusseiten" href="/de/status-pages"> Gebrandete, öffentliche oder passwortgeschützte Status-Seiten für deine Kunden veröffentlichen. </Card> <Card title="Vorfälle" href="/de/incidents"> Verstehen, wie Incidents erkannt, bestätigt und gelöst werden. </Card> <Card title="Wartung" href="/de/maintenance"> Wartungsfenster planen, um Alerts bei geplanten Arbeiten zu unterdrücken. </Card> <Card title="Integrationen" href="/de/integrations"> Slack, Webhooks und weitere Benachrichtigungskanäle anbinden. </Card> <Card title="API Dokumentation" href="/de/api"> Alles per REST-API automatisieren — Kunden, Monitore, Status-Seiten. </Card> </Cards>

## API Reference

### API Dokumentation
URL: https://docs.uptimeify.io/de/api
Description: Übersicht über die REST API. Wähle links eine Ressource aus.
Summary: ## KI / LLM Text-Exporte - [LLMS-Index für KI-Agenten](https://uptimeify.io/llms) - [LLMS-Vollreferenz für KI-Ingestion](https://uptimeify.io/llms-full) - [Deutscher LLMS-Index für KI-Agenten](https://uptimeify.io/de/llms) - [Deutsche LLMS-Vollreferenz für KI-Ingestion](https://uptimeify.io/de/llms-full) ## Base URL Alle Beispiele nutzen eine Platzhalter-Base-URL: ```bash BASE_URL="https://uptimeify.io" ``` ## Authentifizierung Die meisten Endpunkte benötigen Authentifizierung. ```bash TOKEN="wsm_<dein-api-token>" curl -H "Authorization: Bearer $TOKEN" "$BASE_URL/api/websites" ``` API-Tokens aus dem Dashboard starten immer mit `wsm_`. Bitte den kompletten Token (inkl. Prefix) verwenden – sonst kommt `401 Unauthorized`. ## UUID-Pfadparameter Bei migrierten Ressourcen verwenden die Docs und Beispiele die `publicId`-UUID im Pfad. - Nutze UUIDs in Pfaden wie `/api/websites/:websitePublicId`, `/api/customers/:customerPublicId`, `/api/organizations/:organizationPublicId`, `/api/incidents/:incidentPublicId`, `/api/customer-ips/:customerIpPublicId`, `/api/customer-domains/:customerDomainPublicId` und monitor-spezifischen `:...PublicId`-Parametern. - Interne numerische `id`-Felder können in Responses weiterhin vorkommen. - Query-/Body-Felder wie `customerId`, `websiteId` oder `organizationId` bleiben numerisch, sofern die jeweilige Endpoint-Seite nichts anderes sagt. ## Antworten und Fehler - `2xx` bedeutet Erfolg - `4xx` bedeutet Request/Auth-Problem - `5xx` bedeutet Serverfehler - [Fehlerliste und bekannte API-Fallen](./fehlerliste-und-bekannte-fallen) Beispiel-Fehlerantwort: ```json { "statusCode": 401, "statusMessage": "Unauthorized" } ```

### Globale Administration
URL: https://docs.uptimeify.io/de/api/admin
Description: Dieser Abschnitt deckt die Endpunkte der globalen Administration ab, die geschützt sind und nur für Plattform-Administratoren zugänglich sind.
Summary: *(Endpunkte werden noch dokumentiert)* ## Endpunkte

### API-Tokens
URL: https://docs.uptimeify.io/de/api/api-tokens
Description: API-Tokens ermöglichen den programmatischen Zugriff auf die Uptimeify-API. Tokens haben das Präfix wsm_ und können auf einen bestimmten Kunden oder organisationsweit beschränkt werden.
Summary: Es gibt zwei Endpunkt-Gültigkeitsbereiche: - **Organisations-Tokens** (`/api/organization/tokens`) — nur für Admins, voller Organisationszugriff - **Kunden-Tokens** (`/api/customer/tokens`) — beschränkt auf zugängliche Kunden ## Authentifizierung Alle Beispiele setzen ein Session-Cookie voraus (keine API-Tokens — API-Tokens können keine anderen API-Tokens verwalten): ```bash BASE_URL="https://uptimeify.io" ``` ## Endpunkte - [Organisations-Tokens auflisten](./list-organization-tokens) - [Organisations-Token erstellen](./create-organization-token) - [Organisations-Token löschen](./delete-organization-token) - [Kunden-Tokens auflisten](./list-customer-tokens) - [Kunden-Token erstellen](./create-customer-token) - [Kunden-Token löschen](./delete-customer-token)

### Kunden-Token erstellen
URL: https://docs.uptimeify.io/de/api/api-tokens/create-customer-token
Description: Erstellt einen neuen API-Token mit Gültigkeitsbereich für einen Kunden. Eingeschränkte Nutzer müssen customerId angeben. Der vollständige Token wird nur einmal zurückgegeben — bewahre ihn sicher auf.
Summary: `POST /api/customer/tokens` ## Anfrage (Request Body) | Feld | Typ | Erforderlich | Standard | Beschreibung | |-------|------|----------|---------|-------------| | `name` | string | Ja | — | Anzeigename des Tokens (1–255 Zeichen) | | `expiresInDays` | number | Nein | null | Tage bis zum Ablauf (1–365). Null = kein Ablauf. | | `customerId` | number | Nein* | null | Token auf einen bestimmten Kunden beschränken. Erforderlich für eingeschränkte Nutzer. | ## Beispiel (cURL) ```bash curl -X POST "$BASE_URL/api/customer/tokens" \ -H "Cookie: $SESSION_COOKIE" \ -H "Content-Type: application/json" \ -d '{ "name": "Acme Corp API Token", "customerId": 5, "expiresInDays": 180 }' ``` ## Antwort (Response) ```json { "id": 2, "name": "Acme Corp API Token", "token": "wsm_f7e6d5c4b3a2...", "lastUsedAt": null, "expiresAt": "2026-10-15T08:00:00.000Z", "createdAt": "2026-04-15T08:00:00.000Z" } ``` ## Häufige Fehler - `400 Invalid customer ID` wenn die customerId nicht zu deiner Organisation gehört - `400 customerId is required` wenn ein eingeschränkter Nutzer keine customerId angibt - `403 Forbidden` wenn der Kunde außerhalb des Gültigkeitsbereichs des Nutzers liegt

### Organisations-Token erstellen
URL: https://docs.uptimeify.io/de/api/api-tokens/create-organization-token
Description: Erstellt einen neuen API-Token. Der vollständige Token wird nur einmal zurückgegeben — bewahre ihn sicher auf. Erfordert die Admin-Rolle.
Summary: `POST /api/organization/tokens` ## Anfrage (Request Body) | Feld | Typ | Erforderlich | Standard | Beschreibung | |-------|------|----------|---------|-------------| | `name` | string | Ja | — | Anzeigename des Tokens (1–255 Zeichen) | | `expiresInDays` | number | Nein | null | Tage bis zum Ablauf (1–365). Null = kein Ablauf. | | `customerId` | number | Nein | null | Token auf einen bestimmten Kunden beschränken (muss zu deiner Organisation gehören) | ## Beispiel (cURL) ```bash curl -X POST "$BASE_URL/api/organization/tokens" \ -H "Cookie: $SESSION_COOKIE" \ -H "Content-Type: application/json" \ -d '{ "name": "Production API", "expiresInDays": 90 }' ``` ## Antwort (Response) ```json { "id": 1, "name": "Production API", "token": "wsm_a1b2c3d4e5f6...", "lastUsedAt": null, "expiresAt": "2026-07-15T10:00:00.000Z", "createdAt": "2026-04-15T10:00:00.000Z" } ``` ## Häufige Fehler - `400 Invalid customer ID` wenn die customerId nicht zu deiner Organisation gehört - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du kein Admin bist

### Kunden-Token löschen
URL: https://docs.uptimeify.io/de/api/api-tokens/delete-customer-token
Description: Widerruft einen kundenbezogenen API-Token dauerhaft. Nutzer können nur Tokens innerhalb ihres Kunden-Gültigkeitsbereichs löschen.
Summary: `DELETE /api/customer/tokens/:id` ## Beispiel (cURL) ```bash curl -X DELETE "$BASE_URL/api/customer/tokens/2" \ -H "Cookie: $SESSION_COOKIE" ``` ## Antwort (Response) ```json { "success": true } ``` ## Häufige Fehler - `403 Forbidden` wenn der Token außerhalb deines Kunden-Gültigkeitsbereichs liegt oder wenn der Token organisationsweit ist (kein `customerId`) - `404 Token not found` wenn der Token nicht existiert oder zu einer anderen Organisation gehört

### Organisations-Token löschen
URL: https://docs.uptimeify.io/de/api/api-tokens/delete-organization-token
Description: Widerruft einen API-Token dauerhaft. Erfordert die Admin-Rolle.
Summary: `DELETE /api/organization/tokens/:id` ## Beispiel (cURL) ```bash curl -X DELETE "$BASE_URL/api/organization/tokens/1" \ -H "Cookie: $SESSION_COOKIE" ``` ## Antwort (Response) ```json { "success": true } ``` ## Häufige Fehler - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du kein Admin bist - `404 Token not found` wenn der Token nicht existiert oder zu einer anderen Organisation gehört

### Kunden-Tokens auflisten
URL: https://docs.uptimeify.io/de/api/api-tokens/list-customer-tokens
Description: Gibt die für den aktuellen Nutzer sichtbaren API-Tokens zurück. Eingeschränkte Nutzer sehen nur ihre kundenbezogenen Tokens; Admins sehen alle Tokens. Tokens sind maskiert — nur die ersten 8 Zeichen werden angezeigt.
Summary: `GET /api/customer/tokens` ## Beispiel (cURL) ```bash curl -X GET "$BASE_URL/api/customer/tokens" \ -H "Cookie: $SESSION_COOKIE" \ -H "Accept: application/json" ``` ## Antwort (Response) ```json [ { "id": 2, "organizationId": 1, "name": "Customer Scoped Token", "customerId": 5, "customerName": "Acme Corp", "lastUsedAt": null, "expiresAt": null, "createdAt": "2026-02-01T08:00:00.000Z", "tokenHint": "wsm_f7e6d5..." } ] ``` ## Häufige Fehler - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn der Nutzer keinen Lesezugriff hat

### Organisations-Tokens auflisten
URL: https://docs.uptimeify.io/de/api/api-tokens/list-organization-tokens
Description: Gibt alle API-Tokens der Organisation zurück. Tokens sind maskiert — nur die ersten 8 Zeichen werden angezeigt. Erfordert die Admin-Rolle.
Summary: `GET /api/organization/tokens` ## Beispiel (cURL) ```bash curl -X GET "$BASE_URL/api/organization/tokens" \ -H "Cookie: $SESSION_COOKIE" \ -H "Accept: application/json" ``` ## Antwort (Response) ```json [ { "id": 1, "organizationId": 1, "name": "Production API", "customerId": null, "customerName": null, "lastUsedAt": "2026-04-01T12:00:00.000Z", "expiresAt": null, "createdAt": "2026-01-15T10:00:00.000Z", "tokenHint": "wsm_a1b2c..." } ] ``` ## Häufige Fehler - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du kein Admin bist

### Benutzer & Sitzung
URL: https://docs.uptimeify.io/de/api/auth
Description: Verwalte deine aktuelle Benutzersitzung und rufe Profilinformationen ab.
Summary: ## Endpunkte - [Aktuellen Benutzer abrufen](./aktuellen-nutzer-abfragen)

### Aktuellen Benutzer abrufen
URL: https://docs.uptimeify.io/de/api/auth/get-current-user
Description: Gibt eine reduzierte Sicht auf den aktuell authentifizierten Benutzer und seine Sitzung zurück.
Summary: `GET /api/auth/get-session` ## Anfrage (Request) ```http GET /api/auth/get-session HTTP/1.1 ``` Dieser Endpoint liefert ein öffentlich unkritisches Session-Payload. Für Integrationen nutze API-Tokens (`Authorization: Bearer wsm_...`) mit den REST-Endpunkten unter `/api/**`. Interne Felder wie `email`, `role`, `language`, `isGlobalAdmin`, `isGlobalSupporter`, `emailVerified`, `image` und der Platform-Admin-Customer-Context werden absichtlich nicht zurückgegeben. ## Antwort (Response) ```json { "user": { "id": "user_12345", "name": "Max Mustermann", "firstName": "Max", "lastName": "Mustermann", "organizationId": 1, "organizationStatus": "active", "isActive": true, "createdAt": "2026-03-31T15:50:49.030Z", "updatedAt": "2026-03-31T15:50:49.030Z" }, "session": { "userId": "user_12345", "expiresAt": "2027-03-31T15:58:26.618Z", "token": "session-token-value" } } ```

### Change Requests
URL: https://docs.uptimeify.io/de/api/change-requests
Description: Wie Kunden Änderungen an Managed-Monitoren anfragen und Organisationen sie bearbeiten.
Summary: Monitore mit `managementType: managed` sind für kunden-gescopte Nutzer schreibgeschützt (siehe [Managed vs. Self-Service Monitore](/de/monitoring/managed-vs-self-service)). Statt direkt zu bearbeiten, eröffnet ein Kunde einen **Change Request** gegen den Monitor; die Organisation prüft ihn im Posteingang und nimmt ihn an oder lehnt ab. Ein Change Request hat einen `kind`: | Kind | Bedeutung | Effekt bei Annahme | |---|---|---| | `change` | Freitext-Änderungswunsch für einen Managed-Monitor | Keiner automatisch — die Org setzt die Änderung manuell um | | `request_managed` | Der Kunde bittet die Org, die Verantwortung für einen Monitor zu übernehmen | Der Monitor wird automatisch auf `managed` umgestellt | Endpunkte: - [Change Request anlegen](/de/api/change-requests/create-change-request) — `POST /api/monitors/:monitorType/:monitorId/change-requests` (Kunde oder Org) - [Change Requests auflisten](/de/api/change-requests/list-change-requests) — `GET /api/change-requests` (Org-Admins) - [Change Request auflösen](/de/api/change-requests/resolve-change-request) — `PATCH /api/change-requests/:id` (Org-Admins) Offene Anfragen sind auf **10 pro Kunde** über alle Monitor-Typen begrenzt; weitere Creates liefern `429` (`tooManyOpenRequests`).

### Change Request anlegen
URL: https://docs.uptimeify.io/de/api/change-requests/create-change-request
Description: Eröffnet einen Change Request gegen einen beliebigen Monitor (alle Monitor-Typen).
Summary: `POST /api/monitors/:monitorType/:monitorId/change-requests` Lesezugriff auf den Monitor genügt — der typische Aufrufer ist ein Kundenportal-Nutzer, der auf einem `managed`-Monitor *keinen* Schreibzugriff hat. ## Pfad-Parameter | Parameter | Beschreibung | |---|---| | `monitorType` | Einer von `website`, `dns`, `icmp`, `smtp`, `ssh`, `ftp`, `imap_pop`, `domain`, `dnsbl` | | `monitorId` | Numerische ID des Monitors | ## Request Body | Feld | Typ | Pflicht | Standard | Beschreibung | |------|-----|---------|----------|--------------| | `kind` | string | Nein | `change` | `change` (Freitext-Wunsch) oder `request_managed` (die Org bitten, den Monitor zu übernehmen) | | `message` | string | Ja | — | Der Anfragetext (1–2000 Zeichen) | ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<your-api-token>" curl -X POST "$BASE_URL/api/monitors/website/103/change-requests" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "kind": "change", "message": "Bitte das Check-Intervall auf 1 Minute senken." }' ``` ## Response ```json { "id": 12, "status": "open" } ``` ## Häufige Fehler - `400 Invalid monitor type` (`invalidMonitorType`), wenn `monitorType` keiner der unterstützten Typen ist - `400 Invalid monitor identifier`, wenn `monitorId` keine positive Ganzzahl ist - `401 Unauthorized`, wenn du nicht angemeldet bist - `403 Forbidden` / `404 Not found`, wenn der Monitor außerhalb deines Scopes liegt - `429 Too many open requests` (`tooManyOpenRequests`), wenn der Kunde bereits 10 offene Anfragen hat

### Change Requests auflisten
URL: https://docs.uptimeify.io/de/api/change-requests/list-change-requests
Description: Listet den Change-Request-Posteingang der Organisation.
Summary: `GET /api/change-requests` Erfordert Org-Schreibzugriff (Organisations-Admin oder Global-Admin). Ergebnisse sind strikt auf die Organisation des Aufrufers begrenzt. ## Query-Parameter | Parameter | Typ | Pflicht | Standard | Beschreibung | |---|---|---|---|---| | `status` | string | Nein | `open` | `open`, `accepted` oder `rejected` | ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<your-api-token>" curl "$BASE_URL/api/change-requests?status=open" \ -H "Authorization: Bearer $TOKEN" ``` ## Response Neueste zuerst. `monitorName` wird pro Monitor-Typ aufgelöst; `websiteId` ist ein Legacy-Feld, das nur bei Website-Monitoren befüllt ist. ```json [ { "id": 12, "monitorType": "website", "monitorId": 103, "websiteId": 103, "customerId": 101, "customerName": "Customer A GmbH", "monitorName": "New Landing Page", "requestedBy": "usr_123", "kind": "change", "message": "Bitte das Check-Intervall auf 1 Minute senken.", "status": "open", "resolvedBy": null, "resolvedAt": null, "createdAt": "2026-07-09T10:00:00.000Z" } ] ``` ## Häufige Fehler - `401 Unauthorized`, wenn du nicht angemeldet bist - `403 Forbidden`, wenn du kein Organisations-Admin bist

### Change Request auflösen
URL: https://docs.uptimeify.io/de/api/change-requests/resolve-change-request
Description: Nimmt einen offenen Change Request an oder lehnt ihn ab.
Summary: `PATCH /api/change-requests/:id` Erfordert Org-Schreibzugriff. Der Status-Übergang ist atomar — bei parallelen Auflösungen gewinnt nur ein Aufrufer; der Verlierer erhält `409`. Das Annehmen einer Anfrage mit `kind: request_managed` stellt den Ziel-Monitor zusätzlich auf `managementType: managed` um (dispatcht in die korrekte Tabelle des Monitor-Typs). ## Request Body | Feld | Typ | Pflicht | Beschreibung | |------|-----|---------|--------------| | `status` | string | Ja | `accepted` oder `rejected` | ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<your-api-token>" curl -X PATCH "$BASE_URL/api/change-requests/12" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "status": "accepted" }' ``` ## Response ```json { "id": 12, "status": "accepted" } ``` ## Häufige Fehler - `400 Invalid change-request identifier` - `401 Unauthorized`, wenn du nicht angemeldet bist - `403 Forbidden`, wenn du kein Organisations-Admin bist - `404 Change request not found` - `409 Change request already resolved`, wenn die Anfrage nicht mehr `open` ist

### Benutzerdefinierte Felder
URL: https://docs.uptimeify.io/de/api/custom-fields
Description: Definiere benutzerdefinierte Metadatenfelder, die an Kunden und Websites angehängt werden können. Benutzerdefinierte Felder unterstützen die Typen Text, Select und Multi-Select.
Summary: ## Authentifizierung Alle Beispiele setzen ein Bearer-Token voraus: ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" ``` ## Endpunkte - [Benutzerdefinierte Felder auflisten](./list-custom-fields) - [Benutzerdefiniertes Feld erstellen](./create-custom-field) - [Benutzerdefiniertes Feld aktualisieren](./update-custom-field) - [Benutzerdefiniertes Feld löschen](./delete-custom-field)

### Benutzerdefiniertes Feld erstellen
URL: https://docs.uptimeify.io/de/api/custom-fields/create-custom-field
Description: Erstellt eine neue Definition für ein benutzerdefiniertes Feld.
Summary: `POST /api/custom-fields` ## Anfrage (Request Body) | Feld | Typ | Erforderlich | Standard | Beschreibung | |-------|------|----------|---------|-------------| | `organizationId` | number | Ja | — | Organisations-ID | | `name` | string | Ja | — | Anzeigename | | `fieldKey` | string | Nein | auto aus name | Eindeutiger Schlüssel (automatisch normalisiert: Kleinbuchstaben, nicht-alphanumerisch → `_`) | | `fieldType` | string | Nein | `text` | `text`, `select` oder `multiselect` | | `isRequired` | boolean | Nein | false | Ob das Feld erforderlich ist | | `displayOrder` | number | Nein | 0 | Sortierreihenfolge | | `options` | array | Nein | `[]` | Optionen für die Typen select/multiselect | | `placeholder` | string\|null | Nein | null | Platzhaltertext | | `helpText` | string\|null | Nein | null | Hilfetext unterhalb des Feldes | | `showInTable` | boolean | Nein | true | In Tabellenansichten anzeigen | ## Beispiel (cURL) ```bash curl -X POST "$BASE_URL/api/custom-fields" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "organizationId": 1, "name": "Environment", "fieldType": "select", "options": ["production", "staging", "development"], "isRequired": true, "showInTable": true }' ``` ## Häufige Fehler - `409 Conflict` wenn `fieldKey` für die Organisation bereits existiert ## Antwort (Response) Gibt das erstellte benutzerdefinierte Feld-Objekt zurück. Siehe [Fehlercodes](/de/api/error-codes-and-known-pitfalls) für Fehlerantworten.

### Benutzerdefiniertes Feld löschen
URL: https://docs.uptimeify.io/de/api/custom-fields/delete-custom-field
Description: Löscht ein benutzerdefiniertes Feld per Soft-Delete (setzt isActive: false).
Summary: `DELETE /api/custom-fields/:id` ## Beispiel (cURL) ```bash curl -X DELETE "$BASE_URL/api/custom-fields/1" \ -H "Authorization: Bearer $TOKEN" ``` ## Antwort (Response) ```json { "success": true, "message": "Custom field deleted successfully" } ```

### Benutzerdefinierte Felder auflisten
URL: https://docs.uptimeify.io/de/api/custom-fields/list-custom-fields
Description: Gibt alle aktiven Definitionen für benutzerdefinierte Felder der Organisation zurück.
Summary: `GET /api/custom-fields` ## Query Parameter | Parameter | Typ | Standard | Beschreibung | |-----------|------|---------|-------------| | `organizationId` | number | Session-Org | Überschreibt den Organisations-Scope | ## Beispiel (cURL) ```bash curl -X GET "$BASE_URL/api/custom-fields" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Antwort (Response) ```json [ { "id": 1, "organizationId": 1, "name": "Data Center", "fieldKey": "data_center", "fieldType": "text", "isRequired": false, "displayOrder": 0, "options": [], "placeholder": "e.g. fsn1", "helpText": "Primary data center location", "showInTable": true, "isActive": true, "createdAt": "2026-01-01T00:00:00.000Z", "updatedAt": "2026-01-01T00:00:00.000Z" } ] ``` Es werden nur aktive Felder (`isActive: true`) zurückgegeben, sortiert nach `displayOrder`.

### Benutzerdefiniertes Feld aktualisieren
URL: https://docs.uptimeify.io/de/api/custom-fields/update-custom-field
Description: Aktualisiert die Definition eines benutzerdefinierten Feldes. Alle Felder sind optional.
Summary: `PATCH /api/custom-fields/:id` ## Anfrage (Request Body) (alle optional) | Feld | Typ | Beschreibung | |-------|------|-------------| | `name` | string | Anzeigename | | `fieldType` | string | `text`, `select` oder `multiselect` | | `isRequired` | boolean | Ob das Feld erforderlich ist | | `displayOrder` | number | Sortierreihenfolge | | `options` | array | Optionen für select/multiselect | | `placeholder` | string\|null | Platzhaltertext | | `helpText` | string\|null | Hilfetext | | `showInTable` | boolean | In Tabellenansichten anzeigen | | `isActive` | boolean | Soft-Delete (auf false setzen) | ## Beispiel (cURL) ```bash curl -X PATCH "$BASE_URL/api/custom-fields/1" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "name": "Environment", "options": ["production", "staging", "development", "qa"] }' ``` ## Antwort (Response) Gibt das aktualisierte benutzerdefinierte Feld-Objekt zurück. Siehe [Fehlercodes](/de/api/error-codes-and-known-pitfalls) für Fehlerantworten.

### Kunden-Verwaltung
URL: https://docs.uptimeify.io/de/api/customers
Description: Pfadbasierte Kunden-Endpunkte verwenden customerPublicId-UUIDs.
Summary: ## Endpunkte - [Kunden auflisten](./kunden-auflisten) - [Kunden erstellen](./kunden-erstellen) - [Kunden-Details abrufen](./kunden-details-abfragen) - [Kunden aktualisieren](./kunden-aktualisieren) - [Paket wechseln](./paket-wechseln) - [Kunden kündigen](./kunden-kuendigen)

### Paket wechseln
URL: https://docs.uptimeify.io/de/api/customers/change-package
Description: Ändert die Paketzuordnung des Kunden.
Summary: `PATCH /api/customers/:customerPublicId` Technisch ist das derselbe Endpoint wie [Kunden aktualisieren](./kunden-aktualisieren) — normalerweise sendest du hier `packageId`. Legacy-`packageType`-Werte werden aus Kompatibilitätsgründen weiterhin akzeptiert. ## Authentifizierung ```bash BASE_URL="https://uptimeify.io" TOKEN="<your-api-token>" ``` ## Anfrage (Request Body) ```json { "packageId": 12 } ``` ## Beispiel-Request ```bash curl -X PATCH "$BASE_URL/api/customers/6bfec6f6-245a-47ce-843b-157d97d56f88" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "packageId": 12 }' ``` ## Beispiel-Response ```json { "id": 101, "publicId": "6bfec6f6-245a-47ce-843b-157d97d56f88", "organizationId": 1, "name": "Customer A GmbH", "email": "contact@customer-a.de", "notificationPhoneNumber": null, "notificationEmail": null, "packageId": 12, "status": "active", "monthlyReportsEnabled": true, "customFields": {}, "notificationChannels": null, "notificationTargets": null, "updatedAt": "2026-02-26T19:37:00.000Z" } ``` ## Häufige Fehler - `400` Invalid Customer identifier - `401` Unauthorized - `403` Forbidden / Organization ID not found - `404` Customer not found - `500` Failed to update customer

### Kunden erstellen
URL: https://docs.uptimeify.io/de/api/customers/create-customer
Description: Erstellt einen neuen Kunden und weist über packageType ein organisationsdefiniertes Paket zu.
Summary: `POST /api/customers` ## Authentifizierung Dieser Endpoint erfordert Authentifizierung. ```bash BASE_URL="https://uptimeify.io" TOKEN="wsm_<dein-api-token>" ``` ## Anfrage (Request Body) ```json { "name": "Kundenname", "email": "kunde@example.com", "packageType": "business", // konfigurierter packageType oder Display-Name aus der Paket-Konfiguration der Organisation "organizationId": 1, // optional (nur für Global Admins erforderlich) "status": "active", // optional, Standard: active "customFields": { ... } // optional } ``` Hinweise: - `packageType` kann den konfigurierten Paket-Key oder den Display-Namen des Pakets enthalten. Bekannte Alias-Schreibweisen wie `aquisition_test` werden automatisch normalisiert. - Wenn kein konfiguriertes Paket dazu passt, wird der Request mit `400 Bad Request` abgelehnt. - Für normale Benutzer wird `organizationId` aus der Session/dem Token abgeleitet und darf nicht überschrieben werden. - Für Global Admins muss `organizationId` explizit angegeben werden. ## Ownership- & Berechtigungs-Overrides (optional) Diese Felder steuern die [Managed-vs.-Self-Service](/de/monitoring/managed-vs-self-service)-Berechtigungen des Kunden und die Kanal-Typ-Policy. Sie sind **org-write-gated**: Nur Organisations-Admins (oder Global-Admins) können sie setzen — Werte eines Nicht-Admin-Aufrufers werden ignoriert, es gelten die Schema-Standards. `null` (oder das Weglassen des Felds) bedeutet *von der Paket-Konfiguration des Kunden erben*. | Feld | Typ | Standard | Beschreibung | |------|-----|----------|--------------| | `allowSelfService` | boolean\|null | null (erben) | Ob der Kunde `self_service`-Monitore anlegen und verwalten darf | | `maxSelfServiceUrls` | number\|null | null (erben) | Obergrenze für die **Gesamtzahl** der `self_service`-Monitore des Kunden über alle Monitor-Typen | | `canEditManaged` | boolean | false | Ausnahme: erlaubt diesem Kunden, `managed`-Monitore zu bearbeiten (Klassen-Wechsel bleiben org-only). Vergaben werden ins Audit-Log geschrieben. | | `enableEmailAlerts` | boolean\|null | null (erben) | Kanal-Typ-Policy-Override — E-Mail-Alarme | | `enableSmsAlerts` | boolean\|null | null (erben) | Kanal-Typ-Policy-Override — SMS-Alarme | | `enableWebhookAlerts` | boolean\|null | null (erben) | Kanal-Typ-Policy-Override — Webhooks | | `enableIntegrationAlerts` | boolean\|null | null (erben) | Kanal-Typ-Policy-Override — Integrationen | | `enablePostRequestEscalation` | boolean\|null | null (erben) | Kanal-Typ-Policy-Override — POST-Request-Eskalation | Der Legacy-`notificationChannels`-JSONB-Override ist deprecated: Die Kanal-Typ-Policy liegt in den `enable*`-Feldern oben. ## Response ```json { "success": true, "customer": { "id": 64, "publicId": "6d74c32b-a97c-49b9-be3e-2b5e24bed826", "organizationId": 2, "name": "Example Customer", "email": "example@test.com", "notificationPhoneNumber": null, "notificationEmail": null, "packageId": 7, "packageType": "essential", "status": "active", "allowedCheckCountryCodes": null, "cancellationDate": null, "cancelledAt": null, "customFields": { "region": "EU", "planOwner": "Operations" }, "monthlyReportsEnabled": true, "notificationChannels": null, "notificationTargets": null, "notificationRules": null, "smsUsageCurrentMonth": 0, "createdAt": "2026-04-04T12:27:13.415Z", "updatedAt": "2026-04-04T12:27:13.415Z" } } ```

### Kunden-Details abrufen
URL: https://docs.uptimeify.io/de/api/customers/get-customer-details
Description: Gibt Details eines bestimmten Kunden zurück.
Summary: `GET /api/customers/:customerPublicId` `packageDisplayName` ist das konfigurierte Anzeigename-Label des zugewiesenen Organisations-Pakets. Es ist kein global normalisierter Enum und kann deshalb organisationsspezifische Namen wie `aquisition_test` enthalten. ## Antwort (Response) ```json { "id": 101, "publicId": "6bfec6f6-245a-47ce-843b-157d97d56f88", "organizationId": 1, "name": "Kunde A GmbH", "email": "kontakt@kunde-a.de", "notificationPhoneNumber": "+491701234567", "notificationEmail": "alerts@kunde-a.de", "packageId": 3, "packageDisplayName": "Growth", "status": "active", "customFields": { "interneReferenz": "KD-999" }, "monthlyReportsEnabled": true, "notificationChannels": null, "notificationTargets": null, "notificationRules": null, "smsUsageCurrentMonth": 0, "updatedAt": "2023-05-15T10:00:00Z", "createdAt": "2023-05-15T10:00:00Z" } ``` ## Häufige Fehler - `400` Invalid Customer identifier - `401` Unauthorized - `403` Forbidden / Organization ID not found - `404` Customer not found

### Kunden auflisten
URL: https://docs.uptimeify.io/de/api/customers/list-customers
Description: Listet alle Kunden der Organisation auf.
Summary: `GET /api/customers` ## Query-Parameter - `organizationId` (erforderlich): Die ID der Organisation. - `fields` (optional): Auf `minimal` setzen, um eine schlanke Struktur mit ausschließlich `id`, `publicId`, `name`, `status` und `customFields` zu erhalten — Monitor-Zähler und Paketdetails entfallen, und die Antwort ist deutlich kleiner. Nützlich zum Befüllen von Auswahllisten/Dropdowns. ## Antwort (Response) Mit `fields=minimal`: ```json [ { "id": 101, "publicId": "cus_9f3a…", "name": "Kunde A GmbH", "status": "active", "customFields": { "region": "EU" } } ] ``` Standard-Antwort: ```json [ { "id": 101, "organizationId": 1, "name": "Kunde A GmbH", "email": "kontakt@kunde-a.de", "packageId": 4, "packageDisplayName": "Business", "status": "active", "cancellationDate": null, "notificationEmail": "alerts@kunde-a.de", "createdAt": "2023-05-15T10:00:00Z" }, { "id": 102, "organizationId": 1, "name": "StartUp XY", "email": "info@startup-xy.com", "packageId": 1, "packageDisplayName": "Essential", "status": "marked_for_cancellation", "cancellationDate": "2024-12-31T23:59:59Z", "createdAt": "2023-06-20T14:30:00Z" } ] ``` Hinweis: Die Listen-Response liefert absichtlich keinen rohen `packageType` mehr. Verwende `packageDisplayName` für Anzeigezwecke und `packageId` für technische Zuordnung. `packageDisplayName` stammt aus der zugewiesenen Organisations-Paketkonfiguration und kann deshalb organisationsspezifisch sein.

### Kunden aktualisieren
URL: https://docs.uptimeify.io/de/api/customers/update-customer
Description: Aktualisiert Kundendetails.
Summary: `PATCH /api/customers/:customerPublicId` ## Authentifizierung ```bash BASE_URL="https://uptimeify.io" TOKEN="<your-api-token>" ``` ## Anfrage (Request Body) Alle Felder sind optional. Nicht gesendete Felder behalten ihren aktuellen Wert. ```json { "name": "Neuer Name", "email": "neu@example.com", "status": "active", "packageType": "business", // konfigurierter packageType oder Display-Name der Organisation "notificationEmail": "alerts@customer-a.de", "notificationPhoneNumber": "+491701234567", "monthlyReportsEnabled": true, "customFields": { "internalReference": "KD-999" } } ``` Hinweise: - `packageType` kann den konfigurierten Paket-Key oder den Display-Namen des Pakets enthalten. Bekannte Alias-Schreibweisen wie `aquisition_test` werden automatisch normalisiert. ## Ownership- & Berechtigungs-Overrides (optional) Diese Felder steuern die [Managed-vs.-Self-Service](/de/monitoring/managed-vs-self-service)-Berechtigungen des Kunden und die Kanal-Typ-Policy. Sie sind **org-write-gated**: Schreibzugriffe eines kunden-gescopten Aufrufers auf diese Felder werden serverseitig stillschweigend ignoriert. `null` bedeutet *von der Paket-Konfiguration des Kunden erben*. | Feld | Typ | Standard | Beschreibung | |------|-----|----------|--------------| | `allowSelfService` | boolean\|null | null (erben) | Ob der Kunde `self_service`-Monitore anlegen und verwalten darf | | `maxSelfServiceUrls` | number\|null | null (erben) | Obergrenze für die **Gesamtzahl** der `self_service`-Monitore des Kunden über alle Monitor-Typen | | `canEditManaged` | boolean | false | Ausnahme: erlaubt diesem Kunden, `managed`-Monitore zu bearbeiten (Klassen-Wechsel bleiben org-only). Änderungen werden ins Audit-Log geschrieben. | | `enableEmailAlerts` | boolean\|null | null (erben) | Kanal-Typ-Policy-Override — E-Mail-Alarme | | `enableSmsAlerts` | boolean\|null | null (erben) | Kanal-Typ-Policy-Override — SMS-Alarme | | `enableWebhookAlerts` | boolean\|null | null (erben) | Kanal-Typ-Policy-Override — Webhooks | | `enableIntegrationAlerts` | boolean\|null | null (erben) | Kanal-Typ-Policy-Override — Integrationen | | `enablePostRequestEscalation` | boolean\|null | null (erben) | Kanal-Typ-Policy-Override — POST-Request-Eskalation | Der Legacy-`notificationChannels`-JSONB-Override ist deprecated: Die Kanal-Typ-Policy liegt in den `enable*`-Feldern oben. ## Beispiel-Request ```bash curl -X PATCH "$BASE_URL/api/customers/6bfec6f6-245a-47ce-843b-157d97d56f88" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "name": "Customer A GmbH (Updated)", "monthlyReportsEnabled": true }' ``` ## Beispiel-Response ```json { "id": 101, "publicId": "6bfec6f6-245a-47ce-843b-157d97d56f88", "organizationId": 1, "name": "Customer A GmbH (Updated)", "email": "contact@customer-a.de", "notificationPhoneNumber": "+491701234567", "notificationEmail": "alerts@customer-a.de", "packageId": 3, "status": "active", "monthlyReportsEnabled": true, "customFields": { "internalReference": "KD-999" }, "notificationChannels": null, "notificationTargets": null, "updatedAt": "2026-02-26T19:37:00.000Z" } ``` ## Häufige Fehler - `400` Invalid Customer identifier - `401` Unauthorized - `403` Forbidden / Organization ID not found - `404` Customer not found - `500` Failed to update customer

### Fehlerliste und bekannte API-Fallen
URL: https://docs.uptimeify.io/de/api/error-codes-and-known-pitfalls
Description: Diese Seite dokumentiert reale Fehlerbilder, die bei Integrationen aufgetreten sind.
Summary: ## Schema | Error Code | Grund | Lösung / Bug | | --- | --- | --- | | `404 Website not found` | Einige Website-Unterendpunkte haben früher nur die alte numerische Website-ID akzeptiert, obwohl die Docs `websitePublicId` gezeigt haben. | Behoben. `GET /api/websites/:websitePublicId/check-history` und `GET /api/websites/:websitePublicId/uptime-stats` akzeptieren jetzt Public IDs und weiterhin Legacy-IDs. | | `403 Forbidden` auf `GET /api/organizations/:organizationPublicId` | Die Route hat die Pfad-ID früher direkt als Zahl interpretiert. Eine UUID wurde dadurch schon in der Berechtigungsprüfung verworfen. | Behoben. Die Organisations-Detail- und Billing-Routen lösen jetzt `publicId` korrekt auf. | | `400 Bad Request` mit `ZodError` bei `customer-ips` oder `customer-domains` | Query-Parameter wie `organizationId=`, `page=` oder `perPage=` wurden als leere Strings gesendet. Zod coerct leere Strings zu `0`, was dann an den Mindestwerten scheitert. | Behoben für `organizationId`, `page` und `perPage`. Optional bedeutet trotzdem: ungenutzte Parameter komplett weglassen statt leere Strings zu senden. | ## Betroffene Fälle ### Website not found bei Website-Monitoring-Endpunkten Betroffene Endpunkte: - `GET /api/websites/:websitePublicId/check-history` - `GET /api/websites/:websitePublicId/uptime-stats` Früherer Effekt: ```json { "error": true, "statusCode": 404, "statusMessage": "Website not found", "message": "Website not found" } ``` Grund: - Die Route hat nur die alte numerische `id` direkt geparsed. - Eine UUID wurde nicht in die interne numerische ID aufgelöst. Aktueller Stand: - Public IDs funktionieren jetzt wie in der Doku beschrieben. - Legacy-Integer-IDs bleiben aus Kompatibilitätsgründen gültig. ### Forbidden bei Organisations-Details mit Public ID Betroffener Endpoint: - `GET /api/organizations/:organizationPublicId` Grund: - Die Berechtigungsprüfung lief früher gegen `Number(id)`. - Bei einer UUID wurde daraus `NaN`, was zu `403 Forbidden` führte. Aktueller Stand: - Die Route und die Billing-Routen lösen `organizationPublicId` jetzt korrekt in die interne ID auf. ### ZodError bei optionalen Listen-Parametern Betroffene Endpunkte: - `GET /api/customer-ips` - `GET /api/customer-domains` Typisches Muster: ```json { "error": true, "statusCode": 400, "statusMessage": "Bad Request" } ``` Grund: - Nicht das Weglassen der Parameter war das Problem. - Das Problem waren leere Query-Werte wie `?page=&perPage=`. Lösung: - Unbenutzte optionale Parameter weglassen. - Die API ignoriert für diese Felder jetzt leere Strings robuster. ## Monitor-Ownership-Fehlercodes Seit dem [Managed-vs.-Self-Service](/de/monitoring/managed-vs-self-service)-Modell können Monitor-Schreib-Endpunkte **aller** Typen (Website, DNS, ICMP, SMTP, SSH, FTP, IMAP/POP, Domain, DNSBL) diese `403`-Codes in `data.code` liefern: | Code | Bedeutung | | --- | --- | | `managed_by_organization` | Ein kunden-gescopter Aufrufer wollte einen `managed`-Monitor ohne die `canEditManaged`-Ausnahme bearbeiten/löschen. Stattdessen einen [Change Request](/de/api/change-requests) eröffnen. | | `selfServiceNotAllowed` | Ein kunden-gescopter Aufrufer wollte einen Monitor anlegen, aber das aufgelöste `allowSelfService` des Kunden ist false. | | `selfServiceQuotaReached` | Das Anlegen (oder Umstellen auf) eines `self_service`-Monitors würde `maxSelfServiceUrls` des Kunden überschreiten — das Kontingent zählt **alle** Monitor-Typen zusammen. | | `managementTypeOrgOnly` | Ein Nicht-Org-Admin wollte den `managementType` eines Monitors ändern. Klassen-Wechsel sind Organisations-Admins vorbehalten. | | `tooManyOpenRequests` | (`429`) Der Kunde hat bereits 10 offene Change Requests. | ## Incident-Fehlercodes Nur manuelle (Statusseiten-)Incidents können gelöscht werden. `DELETE /api/incidents/:id` liefert diesen `data.code`: | Code | Bedeutung | | --- | --- | | `notManualIncident` | (`403`) Der Incident wurde vom Monitoring erzeugt. Nur von einem Admin erstellte manuelle Incidents können gelösch…

### Eskalations-Konfiguration
URL: https://docs.uptimeify.io/de/api/escalation
Description: Verwalte die Webhook-Eskalationseinstellungen auf Organisationsebene sowie die Standard-Benachrichtigungskanäle.
Summary: Die Eskalations-Konfiguration wird beim ersten Zugriff automatisch mit sinnvollen Standardwerten angelegt. ## Authentifizierung Alle Endpunkte akzeptieren entweder Session-Cookies oder API-Bearer-Tokens: ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" ``` ## Variablen für die Standard-Webhook-Body-Vorlage | Variable | Beschreibung | |----------|-------------| | `{{websiteName}}` | Name der betroffenen Website | | `{{websiteUrl}}` | URL der betroffenen Website | | `{{status}}` | Aktueller Status (z. B. `down`, `up`) | | `{{startedAt}}` | Zeitstempel des Vorfallbeginns | | `{{incident}}` | Objekt mit den Vorfalldetails | | `{{errorMessage}}` | Fehlermeldung, falls verfügbar | ## Endpunkte - [Eskalations-Konfiguration abrufen](./get-escalation-config) - [Eskalations-Konfiguration aktualisieren](./update-escalation-config) - [Eskalations-Konfiguration testen](./test-escalation-config)

### Eskalations-Konfiguration abrufen
URL: https://docs.uptimeify.io/de/api/escalation/get-escalation-config
Description: Gibt die Eskalations-Konfiguration einer Organisation zurück. Der Parameter :id ist die Organisations-ID. Falls noch keine Konfiguration existiert, wird automatisch eine mit Standardwerten angelegt.
Summary: `GET /api/escalation-config/:id` Gibt außerdem die Standard-Benachrichtigungseinstellungen der Organisation sowie alle Benachrichtigungskanäle zurück. ## Beispiel (cURL) ```bash curl -X GET "$BASE_URL/api/escalation-config/1" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Antwort (Response) ```json { "id": 1, "organizationId": 1, "webhookUrl": "https://example.com/webhook", "webhookMethod": "POST", "webhookHeaders": { "Content-Type": "application/json" }, "webhookBodyTemplate": "{\"websiteName\":\"{{websiteName}}\",...}", "webhookTimeout": 30, "webhookRetryAttempts": 3, "webhookRetryDelay": 60, "expectedStatusCodes": "200,201,202,204", "isActive": false, "lastTestedAt": null, "lastTestStatus": null, "lastTestError": null, "organization": { "defaultEmail": "ops@example.com", "defaultPhoneNumber": "+1234567890", "defaultNotificationChannels": null, "defaultNotificationTargets": null, "defaultNotificationRules": null }, "notificationChannels": [] } ``` ## Häufige Fehler - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keine ausreichenden Berechtigungen hast

### Eskalations-Konfiguration testen
URL: https://docs.uptimeify.io/de/api/escalation/test-escalation-config
Description: Testet die Eskalations-Konfiguration, indem ein Test-Webhook, ein PagerDuty-Event oder eine Pushover-Benachrichtigung gesendet wird. Alle Body-Felder sind optional und überschreiben für den Test die in der DB gespeicherten Werte.
Summary: `POST /api/escalation-config/:id/test` ## Anfrage (Request Body) (alle optional) | Feld | Typ | Beschreibung | |-------|------|-------------| | `type` | string | `pagerduty` oder `pushover` für dedizierte Handler | | `config` | object | PagerDuty-Konfiguration `{routingKey}` oder Pushover-Konfiguration `{userKey, apiToken}` | | `webhookUrl` | string | Überschreibt die Webhook-URL für den Test | | `webhookMethod` | string | Überschreibt die Webhook-Methode | | `webhookHeaders` | object | Überschreibt die Webhook-Header | | `webhookBodyTemplate` | string | Überschreibt die Webhook-Body-Vorlage | | `webhookTimeout` | number | Überschreibt das Webhook-Timeout | | `expectedStatusCodes` | string | Überschreibt die erwarteten Statuscodes | ## Beispiel (cURL) — Webhook-Test ```bash curl -X POST "$BASE_URL/api/escalation-config/1/test" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "webhookUrl": "https://httpbin.org/post", "webhookMethod": "POST", "webhookTimeout": 15 }' ``` ## Beispiel (cURL) — PagerDuty-Test ```bash curl -X POST "$BASE_URL/api/escalation-config/1/test" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "type": "pagerduty", "config": { "routingKey": "your-routing-key-here" } }' ``` ## Antwort (Response) (Webhook) ```json { "success": true, "statusCode": 200, "message": "Webhook delivered successfully" } ``` ## Antwort (Response) (PagerDuty) ```json { "success": true, "message": "PagerDuty event enqueued successfully" } ``` ## Häufige Fehler - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keine ausreichenden Berechtigungen hast

### Eskalations-Konfiguration aktualisieren
URL: https://docs.uptimeify.io/de/api/escalation/update-escalation-config
Description: Aktualisiert die Eskalations-Konfiguration. Der Parameter :id ist die Organisations-ID. Falls noch keine Konfiguration existiert, wird per Upsert eine angelegt.
Summary: `PATCH /api/escalation-config/:id` ## Anfrage (Request Body) (alle optional) | Feld | Typ | Beschreibung | |-------|------|-------------| | `webhookUrl` | string\|null | Webhook-URL. Auf `null` setzen, um den Webhook-Kanal zu deaktivieren. | | `webhookMethod` | string | HTTP-Methode: `POST`, `PUT` oder `PATCH` | | `webhookHeaders` | object\|string | JSON-Header-Objekt | | `webhookBodyTemplate` | string | JSON-Body-Vorlage mit `{{variables}}` | | `webhookTimeout` | integer | Timeout in Sekunden | | `webhookRetryAttempts` | integer | Anzahl der Wiederholungsversuche | | `webhookRetryDelay` | integer | Sekunden zwischen den Wiederholungsversuchen | | `expectedStatusCodes` | string | Kommagetrennte erwartete Statuscodes | | `isActive` | boolean | Aktiviert oder deaktiviert den Webhook | | `defaultEmail` | string | **Nebeneffekt:** legt einen E-Mail-Benachrichtigungskanal auf Organisationsebene an oder aktualisiert ihn | | `defaultPhoneNumber` | string | **Nebeneffekt:** legt einen SMS-Benachrichtigungskanal auf Organisationsebene an oder aktualisiert ihn | ## Beispiel (cURL) ```bash curl -X PATCH "$BASE_URL/api/escalation-config/1" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "webhookUrl": "https://example.com/webhook", "webhookMethod": "POST", "webhookHeaders": { "Content-Type": "application/json" }, "webhookTimeout": 30, "webhookRetryAttempts": 3, "isActive": true, "defaultEmail": "alerts@example.com" }' ``` ## Häufige Fehler - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keine ausreichenden Berechtigungen hast ## Antwort (Response) Gibt das aktualisierte Objekt der Eskalations-Konfiguration zurück. Siehe [Error Codes](/de/api/error-codes-and-known-pitfalls) für Fehler-Antworten.

### Beispiele
URL: https://docs.uptimeify.io/de/api/examples
Description: Hier findest du Schritt-für-Schritt Beispiele für häufige API-Workflows.
Summary: - [Kunde + Website erstellen](/de/api/examples/create-customer-and-website) - [Kunde inkl. aller Websites löschen](/de/api/examples/delete-customer-and-all-websites) - [Kunde + alle Monitore anlegen](/de/api/examples/create-customer-and-all-monitors) - [Kunde + mehrere Monitore anlegen](/de/api/examples/create-customer-and-multiple-monitors)

### Kunde + alle Monitore anlegen
URL: https://docs.uptimeify.io/de/api/examples/create-customer-and-all-monitors
Description: Dieses Beispiel ist praktisch, wenn du einen Kunden mit einem kompletten Monitoring-Baseline-Setup initialisieren möchtest.
Summary: High-level Flow: 1. Kunde erstellen 2. Website erstellen 3. Monitore anlegen (je Monitor-Typ einen) ## 1) Kunde + Website erstellen Nutze dafür: - [Kunde + Website erstellen](/de/api/examples/create-customer-and-website) ## 2) Monitore anlegen (je Typ einen) Die Monitor-APIs sind nach Typ organisiert. API-Referenz-Übersicht: - [Monitore API](/de/api/monitors) Typische Monitor-Typen: - DNS Monitor - ICMP Monitor - SMTP Monitor - SSH Monitor - FTP Monitor - IMAP/POP Monitor Die genauen Pflichtfelder findest du in der jeweiligen API-Doku pro Typ. ### Beispiel: DNS Monitor erstellen ```bash curl -X POST "$API_BASE_URL/api/dns-monitors" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "customerId": 123, "name": "DNS: acme.example", "hostname": "acme.example", "dnsConfig": { "rrtypes": ["A", "AAAA"], "matchMode": "exact", "expectedValues": { "A": ["93.184.216.34"], "AAAA": ["2606:2800:220:1:248:1893:25c8:1946"] } } }' ``` ### Beispiel: ICMP Monitor erstellen ```bash curl -X POST "$API_BASE_URL/api/icmp-monitors" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "customerId": 123, "name": "Ping: gateway", "hostname": "gateway.acme.example" }' ``` ## Hinweise - Nicht jede Installation bietet jeden Monitor-Typ an, und Pflichtfelder können je nach Plan/Paket variieren. - Für Website/HTTP Checks startest du meist in den Website-spezifischen Einstellungen: [Website-Konfiguration API](/de/api/website-configuration)

### Kunde + mehrere Monitore anlegen
URL: https://docs.uptimeify.io/de/api/examples/create-customer-and-multiple-monitors
Description: Dieses Beispiel zeigt, wie du für einen Kunden mehrere Monitore einrichtest, z.B.:
Summary: - Zwei unterschiedliche Hostnamen für DNS Monitoring - Mehrere Server für ICMP - Eine Mischung aus DNS + ICMP + SMTP ## 1) Kunde + Website erstellen - [Kunde + Website erstellen](/de/api/examples/create-customer-and-website) ## 2) Mehrere Monitore anlegen ### Option A: Mehrere Monitore vom selben Typ (DNS) ```bash # DNS Monitor 1 curl -X POST "$API_BASE_URL/api/dns-monitors" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "customerId": 123, "name": "DNS: app.acme.example", "hostname": "app.acme.example", "dnsConfig": { "rrtypes": ["A"], "matchMode": "exact", "expectedValues": { "A": ["93.184.216.34"] } } }' # DNS Monitor 2 curl -X POST "$API_BASE_URL/api/dns-monitors" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "customerId": 123, "name": "DNS: mail.acme.example", "hostname": "mail.acme.example", "dnsConfig": { "rrtypes": ["MX", "TXT"], "matchMode": "contains", "expectedValues": { "MX": ["10 mail.acme.example"], "TXT": ["v=spf1 include:_spf.acme.example ~all"] } } }' ``` ### Option B: Gemischte Monitor-Typen ```bash # ICMP curl -X POST "$API_BASE_URL/api/icmp-monitors" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "customerId": 123, "name": "Ping: edge-1", "hostname": "edge-1.acme.example" }' # SMTP curl -X POST "$API_BASE_URL/api/smtp-monitors" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "customerId": 123, "name": "SMTP: outbound", "hostname": "smtp.acme.example", "port": 587 }' ``` ## Tipps - Nutze konsistente Namen (Prefix nach Typ: `DNS:`, `Ping:`, `SMTP:`). - Starte mit konservativen Intervallen und verschärfe später. ## Referenz - [Monitoring-Typen](/monitoring/monitoring-types/uptime) - [Monitore API](/de/api/monitors)

### Kunde + Website erstellen
URL: https://docs.uptimeify.io/de/api/examples/create-customer-and-website
Description: Dieses Beispiel zeigt einen typischen Onboarding-Flow:
Summary: 1. **Kunde** anlegen 2. Eine **Website** für diesen Kunden anlegen 3. (Optional) Monitoring-Konfiguration ergänzen > Wenn du lieber das UI nutzt: Kunden und Websites kannst du im Admin-Bereich anlegen. Die API ist ideal für Automatisierung und Bulk-Setups. ## Voräussetzungen - API Token mit den benötigten Scopes - Deine API Base URL (z.B. `https://your-instance.tld`) Siehe zuerst die API-Einführung: - [API Einführung](/de/api/introduction) ## 1) Kunde erstellen API Referenz: - [Kunden API](/de/api/customers) Beispiel (Pseudo-Request): ```bash curl -X POST "$API_BASE_URL/api/customers" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "name": "Acme GmbH", "email": "ops@acme.example" }' ``` Speichere die zurückgegebene `customerId`. ## 2) Website für den Kunden erstellen API Referenz: - [Websites API](/de/api/websites) ```bash curl -X POST "$API_BASE_URL/api/websites" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "customerId": 123, "name": "Acme Marketing Website", "url": "https://acme.example" }' ``` Wichtig: - `url` muss das Protokoll enthalten (`https://...`). ## 3) Website prüfen API Referenz: - [Website abfragen](/de/api/websites/website-abfragen) ```bash curl -X GET "$API_BASE_URL/api/websites/456" \ -H "Authorization: Bearer $TOKEN" ``` ## Nächste Schritte - Website-spezifische Monitoring-/Alert-Einstellungen: [Website-Konfiguration API](/de/api/website-configuration) - Überblick über alle Monitor-Arten: [Monitoring-Typen](/monitoring/monitoring-types/uptime)

### Kunde inkl. aller Websites löschen
URL: https://docs.uptimeify.io/de/api/examples/delete-customer-and-all-websites
Description: Dieses Beispiel beschreibt einen sicheren, expliziten Lösch-Flow.
Summary: Je nach Konfiguration kann das Löschen eines Kunden Websites automatisch mitlöschen — oder auch nicht. Um Überraschungen zu vermeiden, empfehlen wir, Websites zuerst explizit zu löschen. ## Voräussetzungen - API Token mit den benötigten Scopes ## 1) Websites des Kunden auflisten API Referenz: - [Websites auflisten](/de/api/websites/websites-auflisten) Pseudo-Request: ```bash curl -X GET "$API_BASE_URL/api/websites?customerId=123" \ -H "Authorization: Bearer $TOKEN" ``` Sammle alle Website-IDs. ## 2) Jede Website löschen API Referenz: - [Website löschen](/de/api/websites/website-loeschen) ```bash curl -X DELETE "$API_BASE_URL/api/websites/456" \ -H "Authorization: Bearer $TOKEN" ``` Wiederhole das für alle Websites dieses Kunden. ## 3) Kunden löschen API Referenz: - [Kunden API](/de/api/customers) ```bash curl -X DELETE "$API_BASE_URL/api/customers/123" \ -H "Authorization: Bearer $TOKEN" ``` ## Hinweise - Falls euer Backend Cascade Deletes unterstützt, ist Schritt 2 evtl. optional — explizit bleibt Automatisierung aber vorhersehbar.

### Einführung
URL: https://docs.uptimeify.io/de/api/introduction
Description: Willkommen in der Uptimeify API-Dokumentation. Mit dieser REST API kannst du deine Monitoring-Infrastruktur programmatisch verwalten – z. B. Organisationen, Kunden, Websites und Alerts.
Summary: ## Basis-URL Alle API-Anfragen sollten an die folgende Basis-URL gesendet werden: ``` https://uptimeify.io/api ``` ## Authentifizierung Die API unterstützt **Bearer-Token** Authentifizierung für Integrationen. ### API-Token erstellen 1. Logge dich im Uptimeify-Dashboard ein. 2. Öffne im Dashboard **Einstellungen** > **API**. 3. Klicke auf **Token erstellen**, gib einen Namen an und kopiere das erzeugte Secret. Füge das Token im `Authorization`-Header deiner Anfragen hinzu: ```http Authorization: Bearer <dein_api_token> ``` ### Token Scopes (Organization vs Customer) API-Tokens können optional mit einem **Customer Scope** erstellt werden: - **Organisation-weites Token**: kann Ressourcen über alle Kunden der Organisation hinweg lesen/ändern. - **Customer-Scoped Token**: kann nur Ressourcen (Websites, Wartungsfenster usw.) innerhalb dieses einen Kunden lesen/ändern. Customer-Scoped Tokens sind für Agenturen und externe Integrationen empfehlenswert. Requests außerhalb des Scopes liefern `403 Forbidden`. > **Hinweis:** Session-basierte Authentifizierung (Cookies) wird für die Web-Oberfläche verwendet, ist für Integrationen aber nicht empfohlen. ## Antwortformat Alle Antworten werden im JSON-Format zurückgegeben. ### Erfolgsantwort ```json { "id": 123, "name": "Beispiel-Ressource", "createdAt": "2023-01-01T12:00:00Z" } ``` ### Fehlerantwort Fehler werden mit einem passenden HTTP-Statuscode und einem JSON-Body mit Details zurückgegeben. ```json { "statusCode": 400, "statusMessage": "Bad Request", "message": "Validierung fehlgeschlagen: 'url' ist erforderlich." } ``` ## Rate Limiting Damit der Service stabil bleibt, ist die API rate-limitiert. - **Limit**: 600 Requests pro Minute pro IP - **Header**: `X-RateLimit-Remaining` zeigt dein verbleibendes Kontingent - **Überschreitung**: `429 Too Many Requests` ## Endpunkte - [API-Token erstellen](./api-token-generieren) - [Token-Scopes (Organisation vs. Kunde)](./token-organisation-vs-kunde) - [Erfolgsantwort](./bestaetigungsmeldung) - [Fehlerantwort](./fehlermeldungen)

### Fehlerantwort
URL: https://docs.uptimeify.io/de/api/introduction/error-response
Description: Fehler werden mit einem passenden HTTP-Statuscode und einem JSON-Body mit Details zurückgegeben.
Summary: ```json { "statusCode": 400, "statusMessage": "Bad Request", "message": "Validation failed: 'url' is required." } ``` # Rate Limiting Damit der Service stabil bleibt, ist die API rate-limitiert. - **Limit**: 600 Requests pro Minute pro IP - **Header**: `X-RateLimit-Remaining` zeigt dein verbleibendes Kontingent - **Überschreitung**: `429 Too Many Requests`

### API-Token erstellen
URL: https://docs.uptimeify.io/de/api/introduction/generate-api-token
Description: Schritt-für-Schritt-Anleitung zum Erstellen eines Uptimeify API-Tokens über Einstellungen > API.
Summary: 1. Logge dich im Uptimeify-Dashboard ein. 2. Öffne im Dashboard **Einstellungen** > **API**. 3. Klicke auf **Token erstellen**, gib einen Namen an und kopiere das erzeugte Secret. Füge das Token im `Authorization`-Header deiner Anfragen hinzu: ```http Authorization: Bearer <dein_api_token> ```

### Erfolgsantwort
URL: https://docs.uptimeify.io/de/api/introduction/success-response
Description: Bei Erfolg liefert die API einen JSON-Body mit den angefragten Daten.
Summary: ```json { "id": 123, "name": "Example Resource", "createdAt": "2023-01-01T12:00:00Z" } ```

### Token-Scopes (Organisation vs. Kunde)
URL: https://docs.uptimeify.io/de/api/introduction/token-scopes-organization-vs-customer
Description: API-Tokens können optional mit einem Customer Scope erstellt werden:
Summary: - **Organisation-weites Token**: kann Ressourcen über alle Kunden der Organisation hinweg lesen/ändern. - **Customer-Scoped Token**: kann nur Ressourcen (Websites, Wartungsfenster usw.) innerhalb dieses einen Kunden lesen/ändern. Customer-Scoped Tokens sind für Agenturen und externe Integrationen empfehlenswert. Requests außerhalb des Scopes liefern `403 Forbidden`. > **Hinweis:** Session-basierte Authentifizierung (Cookies) wird für die Web-Oberfläche verwendet, ist für Integrationen aber nicht empfohlen.

### Maintenance Windows
URL: https://docs.uptimeify.io/de/api/maintenance-windows
Description: Erstelle und verwalte Wartungsfenster, um Alarme bei geplanten Arbeiten zu unterdrücken. Fenster können einen einzelnen Monitor, mehrere Monitore, einen gesamten Kunden oder alle Monitore mit einem bestimmten Tag abdecken.
Summary: Wartungsfenster unterdrücken Alarme für die betroffenen Monitore während eines geplanten Zeitraums. Während ein Fenster aktiv ist, gilt der betroffene Monitor als **in Wartung** — es werden keine Alarme ausgelöst und, wenn der Kunde eine Statusseite hat, wird der Service als **Wartung** statt **Beeinträchtigt** angezeigt. ## Zieloptionen Ein Fenster kann Monitore auf vier Arten abdecken (gegenseitig ausschließend, außer dass `targets` und `tagIds` kombiniert werden können): | Modus | Angabe | |-------|--------| | **Einzelner Monitor (Legacy)** | Eines der Legacy-ID-Felder: `websiteId`, `icmpMonitorId`, `smtpMonitorId`, `sshMonitorId`, `ftpMonitorId`, `imapPopMonitorId`, `dnsMonitorId`, `customerIpId`, `customerDomainId` | | **Mehrere Monitore** | `targets: [{ type, id }, ...]` Array | | **Nach Tag (dynamisch)** | `tagIds: [number, ...]` — deckt alle Monitore des Kunden des Fensters ab, die den Tag aktuell tragen; später getaggte Monitore werden automatisch abgedeckt | | **Kunden-Ebene** | `customerId` allein — deckt jeden Monitor des Kunden ab | ## Dynamisches Tag-Verhalten Tag-basierte Fenster werden vom Monitoring-Worker live ausgewertet: Jedes Mal, wenn ein Check-Ergebnis eintrifft, ermittelt der Worker, welche Wartungsfenster auf diesen Monitor zutreffen, indem er die aktuellen Tags des Monitors nachschlägt. Das bedeutet, dass ein Monitor, der *nach* der Fenstererstellung getaggt wird, automatisch abgedeckt ist — ohne das Fenster zu aktualisieren. Das Entfernen eines Tags von einem Monitor beendet die Abdeckung sofort. Tag-Fenster sind an einen einzelnen Kunden gebunden. Es ist nicht möglich, ein organisationsweites Tag-Fenster zu erstellen, das mehrere Kunden umfasst. ## Endpunkte - [Maintenance Windows auflisten](./list) - [Maintenance Window erstellen](./create) - [Maintenance Window abrufen](./get) - [Maintenance Window aktualisieren](./update) - [Maintenance Window löschen](./delete)

### Maintenance Window erstellen
URL: https://docs.uptimeify.io/de/api/maintenance-windows/create
Description: Erstellt ein neues Wartungsfenster. Unterstützt einen einzelnen Monitor (Legacy), mehrere Monitore, tag-basiertes (inkl. organisationsweit) oder kunden-weites Targeting.
Summary: `POST /api/maintenance-windows` ## Body ```json { "name": "Datenbank-Migration", "startTime": "2026-07-10T22:00:00.000Z", "endTime": "2026-07-11T01:00:00.000Z", "targets": [ { "type": "website", "id": 101 }, { "type": "icmp", "id": 5 } ], "tagIds": [7], "description": "Geplante Schema-Migration", "isRecurring": false, "isActive": true } ``` ### Pflichtfelder - `name` (string): Eine freundliche Bezeichnung für das Fenster. - `startTime` (ISO 8601 Datetime): Zeitpunkt, an dem das Fenster beginnt. - `endTime` (ISO 8601 Datetime): Zeitpunkt, an dem das Fenster endet. Muss nach `startTime` liegen. - **Mindestens ein Zielfeld** (siehe unten). ### Zielauswahl (gegenseitig ausschließende Modi) Genau ein Targeting-Modus muss verwendet werden. `targets` und `tagIds` können innerhalb des Multi-Monitor-Modus kombiniert werden. | Feld | Typ | Beschreibung | |------|-----|--------------| | `websiteId` | number | Legacy: einzelner Website-Monitor | | `icmpMonitorId` | number | Legacy: einzelner ICMP-Monitor | | `smtpMonitorId` | number | Legacy: einzelner SMTP-Monitor | | `sshMonitorId` | number | Legacy: einzelner SSH-Monitor | | `ftpMonitorId` | number | Legacy: einzelner FTP-Monitor | | `imapPopMonitorId` | number | Legacy: einzelner IMAP/POP-Monitor | | `dnsMonitorId` | number | Legacy: einzelner DNS-Monitor | | `customerIpId` | number | Legacy: einzelne Kunden-IP | | `customerDomainId` | number | Legacy: einzelne Kunden-Domain | | `targets` | `{ type, id }[]` | Multi-Monitor: `type` ist eines von `website` \| `dns` \| `icmp` \| `smtp` \| `ssh` \| `ftp` \| `imap_pop` | | `tagIds` | number[] | Tag-basiert: siehe [Nur-Tag-Modus (organisationsweit)](#nur-tag-modus-organisationsweit) | | `customerId` | number | Kunden-Ebene: deckt jeden Monitor dieses Kunden ab | ### Nur-Tag-Modus (organisationsweit) Wird `tagIds` **ohne** `customerId`, `targets` oder Legacy-Felder gesendet, entsteht ein **organisationsweites** Wartungsfenster. Es deckt dynamisch jeden Monitor der gesamten Organisation ab, der aktuell die angegebenen Tags trägt — über alle Kunden hinweg. ```json { "name": "Infra-Tag-Freeze", "startTime": "2026-07-10T22:00:00.000Z", "endTime": "2026-07-11T01:00:00.000Z", "tagIds": [7] } ``` - **Erfordert Admin- oder Editor-Rolle.** Readonly-Benutzer, die dies versuchen, erhalten `403 Forbidden`. - Die Tag-Zugehörigkeit wird live zur Prüfzeit aufgelöst — nach der Fenstererstellung getaggte Monitore werden automatisch abgedeckt. - Alle `tagIds` müssen zur selben Organisation gehören; das Mischen von Tags verschiedener Organisationen gibt `400 mixedTagOrganizations` zurück. ### Kombinationsregeln - **Mindestens ein** Zielfeld ist erforderlich. Das Weglassen aller Felder ist ein Zod-Validierungsfehler (Standard-`400` mit Validierungsantwort, **kein** `data.code`-Fehler). - **`customerId` (Kunden-Ebene-Modus)** kann nicht mit `targets`, `tagIds` oder Legacy-Feldern kombiniert werden. Das Kombinieren ist ein Zod-Validierungsfehler (Standard-`400`). - Alle Monitore in `targets` müssen zum **selben Kunden** gehören; das Mischen von Kunden gibt `{ data: { code: "mixedCustomers" } }` zurück. - Alle `tagIds` müssen zur selben Organisation gehören; das Mischen gibt `{ data: { code: "mixedTagOrganizations" } }` zurück. ### Optionale Felder | Feld | Typ | Beschreibung | |------|-----|--------------| | `description` | string | Freitext-Notizen (erscheinen in der Historie). | | `isRecurring` | boolean | Standard `false`. Auf `true` setzen, um `recurrencePattern` zu aktivieren. | | `recurrencePattern` | object | Erforderlich, wenn `isRecurring` `true` ist. Siehe [Wiederholung](#wiederholung). | | `isActive` | boolean | Standard `true`. Auf `false` setzen, um ein deaktiviertes Fenster zu erstellen. | ### Wiederholung ```json { "frequency": "weekly", "interval": 1, "daysOfWeek": [1, 3], "dayOfMonth": null, "endRecurrenceDate": "2026-12-31" } ``` | Feld | Werte | |------|-------| | `frequency` | `daily` \| `weekly` \| `monthly` | | `interval` | Ganzzahl ≥ 1 (Wie…

### Maintenance Window löschen
URL: https://docs.uptimeify.io/de/api/maintenance-windows/delete
Description: Löscht ein Wartungsfenster dauerhaft. Die aktive Alarm-Unterdrückung endet sofort.
Summary: `DELETE /api/maintenance-windows/{id}` ## Pfad-Parameter - `id` (erforderlich): Die numerische ID des zu löschenden Wartungsfensters. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X DELETE "$BASE_URL/api/maintenance-windows/42" \ -H "Authorization: Bearer $TOKEN" ``` ## Antwort (Response) Gibt bei Erfolg `204 No Content` mit leerem Body zurück. ## Häufige Fehler - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf die Organisation hast oder das Fenster nicht im Scope liegt (globale Support-Konten können keine Wartungsfenster löschen) - `404 Not Found` wenn kein Wartungsfenster mit der angegebenen ID existiert

### Maintenance Window abrufen
URL: https://docs.uptimeify.io/de/api/maintenance-windows/get
Description: Gibt ein einzelnes Wartungsfenster anhand seiner ID zurück, einschließlich der vollständigen Ziel- und Tag-Auswahl.
Summary: `GET /api/maintenance-windows/{id}` ## Pfad-Parameter - `id` (erforderlich): Die numerische ID des Wartungsfensters. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/maintenance-windows/42" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Antwort (Response) ```json { "id": 42, "publicId": "aaaaaaaa-aaaa-4aaa-8aaa-aaaaaaaaaaaa", "organizationId": 10, "customerId": 1, "name": "Wöchentliches Deployment", "description": "Rollierendes Update jeden Montag", "startTime": "2026-07-07T02:00:00.000Z", "endTime": "2026-07-07T04:00:00.000Z", "isRecurring": true, "recurrencePattern": { "frequency": "weekly", "interval": 1, "daysOfWeek": [1] }, "isActive": true, "targets": [ { "type": "website", "id": 101 }, { "type": "icmp", "id": 5 } ], "tags": [ { "id": 7, "name": "Production", "color": "red" } ], "websiteId": null, "icmpMonitorId": null, "smtpMonitorId": null, "sshMonitorId": null, "ftpMonitorId": null, "imapPopMonitorId": null, "dnsMonitorId": null, "customerIpId": null, "customerDomainId": null, "createdAt": "2026-06-01T09:00:00.000Z", "updatedAt": "2026-06-01T09:00:00.000Z" } ``` Das `targets`-Array listet alle explizit ausgewählten Monitore auf. Das `tags`-Array listet die Tags auf, deren Monitore dynamisch abgedeckt werden. Beide können gleichzeitig nicht leer sein, wenn das Fenster eine gemischte Multi-Monitor- und Tag-Auswahl verwendet. ## Häufige Fehler - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf die Organisation hast oder das Fenster zu einem nicht zugänglichen Kunden gehört - `404 Not Found` wenn kein Wartungsfenster mit der angegebenen ID existiert

### Maintenance Windows auflisten
URL: https://docs.uptimeify.io/de/api/maintenance-windows/list
Description: Gibt alle Wartungsfenster zurück, die für den authentifizierten Benutzer sichtbar sind, gefiltert nach Organisation und optionalem Kunden-Filter.
Summary: `GET /api/maintenance-windows` ## Query-Parameter - `customerId` (optional): Fenster nach Kunden-ID filtern. - `organizationId` (optional): Standardmäßig die Organisation der Sitzung. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/maintenance-windows?customerId=1" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Antwort (Response) ```json [ { "id": 42, "publicId": "aaaaaaaa-aaaa-4aaa-8aaa-aaaaaaaaaaaa", "organizationId": 10, "customerId": 1, "name": "Wöchentliches Deployment", "description": "Rollierendes Update jeden Montag", "startTime": "2026-07-07T02:00:00.000Z", "endTime": "2026-07-07T04:00:00.000Z", "isRecurring": true, "recurrencePattern": { "frequency": "weekly", "interval": 1, "daysOfWeek": [1] }, "isActive": true, "targets": [ { "type": "website", "id": 101 }, { "type": "icmp", "id": 5 } ], "tags": [ { "id": 7, "name": "Production", "color": "red" } ], "websiteId": null, "icmpMonitorId": null, "smtpMonitorId": null, "sshMonitorId": null, "ftpMonitorId": null, "imapPopMonitorId": null, "dnsMonitorId": null, "customerIpId": null, "customerDomainId": null, "createdAt": "2026-06-01T09:00:00.000Z", "updatedAt": "2026-06-01T09:00:00.000Z" } ] ``` Jedes Fenster enthält: - `targets` — Array von `{ type, id }`-Objekten für alle explizit ausgewählten Monitore (`type` ist eines von `website` | `dns` | `icmp` | `smtp` | `ssh` | `ftp` | `imap_pop`). - `tags` — Array von Tag-Objekten `{ id, name, color }` für tag-basierte Abdeckung; ein leeres Array, wenn das Fenster keine Tag-Auswahl verwendet. - Legacy-Felder für einzelne Ziele (`websiteId`, `icmpMonitorId` usw.) bleiben aus Gründen der Abwärtskompatibilität vorhanden; sie sind `null`, wenn eine Multi-Target- oder Tag-Auswahl verwendet wird. ## Häufige Fehler - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf die Organisation hast

### Maintenance Window aktualisieren
URL: https://docs.uptimeify.io/de/api/maintenance-windows/update
Description: Aktualisiert ein Wartungsfenster partiell. Alle Felder sind optional; nur angegebene Felder werden geändert. Wenn targets oder tagIds angegeben werden, ersetzen sie die bestehende Auswahl vollständig.
Summary: `PATCH /api/maintenance-windows/{id}` ## Pfad-Parameter - `id` (erforderlich): Die numerische ID des zu aktualisierenden Wartungsfensters. ## Body Alle Felder sind optional. Felder weglassen, um sie unverändert zu lassen. ```json { "name": "Erweitertes Deployment-Fenster", "endTime": "2026-07-11T03:00:00.000Z", "targets": [ { "type": "website", "id": 101 }, { "type": "dns", "id": 9 } ], "tagIds": [7, 12], "isActive": true } ``` ### Aktualisierbare Felder | Feld | Typ | Hinweise | |------|-----|----------| | `name` | string | Anzeigename | | `description` | string | Freitext-Notizen | | `startTime` | ISO 8601 Datetime | Neuer Startzeitpunkt | | `endTime` | ISO 8601 Datetime | Neuer Endzeitpunkt; muss nach `startTime` liegen | | `isActive` | boolean | Aktivieren oder deaktivieren ohne Löschen | | `isRecurring` | boolean | Wiederholung umschalten | | `recurrencePattern` | object | Ersetzt das Wiederholungsmuster; Struktur identisch mit create | | `targets` | `{ type, id }[]` | **Ersetzt** die vollständige Menge der expliziten Monitor-Ziele | | `tagIds` | number[] | **Ersetzt** die vollständige Menge der Tag-IDs | | `websiteId` / `icmpMonitorId` / … | number \| null | Legacy-Felder für einzelne Ziele | | `customerId` | number | Kunden-Anker (nur für tag-only Fenster) | ### Ersetz-Semantik für targets und tagIds Wenn `targets` oder `tagIds` im Request-Body enthalten ist, wird die **gesamte bestehende Auswahl** für dieses Feld ersetzt. Um alle expliziten Ziele zu entfernen, sende `"targets": []`; um alle Tags zu entfernen, sende `"tagIds": []`. ### Kombinationsregeln PATCH validiert den Ziel- und Tag-Scope über denselben Resolver wie create, führt jedoch **nicht** den create-zeitigen Zod-superRefine erneut aus. In der Praxis: - `customerId` kann nicht mit `targets`, `tagIds` oder Legacy-Feldern kombiniert werden. - Alle Monitore in `targets` müssen zum selben Kunden gehören; Mischung gibt `{ data: { code: "mixedCustomers" } }` zurück. - Ein organisationsweites Nur-Tag-Fenster (Tags ohne `customerId`, `targets` oder Legacy-Felder) kann von Admin- oder Editor-Benutzern innerhalb der Organisation bearbeitet werden. ### Readonly-Benutzer im Scope Readonly-Benutzer, die dem Kunden des Fensters zugewiesen sind, können Wartungsfenster für diesen Kunden bearbeiten. Globale Support-Konten können dies nicht. Readonly-Benutzer können keine organisationsweiten Nur-Tag-Fenster erstellen oder aktualisieren. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X PATCH "$BASE_URL/api/maintenance-windows/42" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"isActive": false}' ``` ## Antwort (Response) Gibt das aktualisierte Wartungsfenster-Objekt in der gleichen Form zurück wie [Maintenance Window abrufen](./get). ## Häufige Fehler | Status | Beschreibung | |--------|--------------| | `400` (Validierung) | Die Aktualisierung würde das Fenster ohne Ziele zurücklassen, oder `customerId` wird mit anderen Zielfeldern kombiniert. Dies sind Zod-Validierungsfehler; der Response-Body ist ein Standard-Validierungsfehler, **kein** `{ data: { code } }`. | | `400` `{ data: { code: "mixedCustomers" } }` | `targets` enthält Monitore verschiedener Kunden. | | `400` `{ data: { code: "mixedTagOrganizations" } }` | `tagIds` enthält Tags aus verschiedenen Organisationen. | | `401 Unauthorized` | Nicht angemeldet. | | `403 Forbidden` | Kein Zugriff auf das Fenster (globale Support-Konten können nicht bearbeiten), oder readonly-Benutzer versucht einen organisationsweiten Nur-Tag-Scope zu setzen. | | `404 Not Found` | Kein Wartungsfenster mit der angegebenen ID gefunden. | | `404` `{ data: { code: "tagNotFound" } }` | Eine `tagId` existiert nicht in der Organisation. |

### Monitoring-Daten & Berichte
URL: https://docs.uptimeify.io/de/api/monitoring
Description: API-Endpunkte zum Abrufen von Monitoring-Daten, Check-Historien, Incident-Details, Uptime-Statistiken und PDF-Berichten.
Summary: ## Monitoring-Daten ### Metriken abrufen `GET /api/websites/:websitePublicId/uptime-stats` Gibt Uptime-Prozentsätze und durchschnittliche Antwortzeiten (Tag/Monat/Jahr) zurück. ### Letzte Checks abrufen `GET /api/websites/:websitePublicId/check-history` Gibt die letzten Monitoring-Checks einer Website zurück. ### Ausfälle auflisten `GET /api/websites/:websitePublicId/incident-history` Gibt die Incident-Historie einer Website zurück. ### Alert-Historie abrufen `GET /api/websites/:websitePublicId/alert-history` Gibt die letzten Benachrichtigungs-/Eskalations-Versuche für Incidents einer Website zurück. ### Monitoring-Daten abrufen `GET /api/websites/:websitePublicId/monitoring-data?range=day|week|month|year` Gibt aggregierte Timeseries-Daten zurück (Charts). ### Ausfall-Details abrufen `GET /api/incidents/:incidentPublicId` Gibt Details zu einem bestimmten Vorfall zurück. ### Ausfälle auflisten (Organisation) `GET /api/incidents?organizationId=:organizationId` Listet Incidents einer Organisation (zugriffsbeschränkt) auf. ## Berichte ### PDF-Bericht herunterladen `GET /api/websites/:websitePublicId/report.pdf?period=last-week|last-month|last-quarter|last-year&startDate=YYYY-MM-DD&endDate=YYYY-MM-DD` Lädt einen PDF-Bericht für eine Website herunter. ## Endpunkte - [Metriken abrufen](./metriken-abfragen) - [Letzte Checks abrufen](./letzte-checks-abfragen) - [Ausfälle auflisten](./ausfaelle-auflisten) - [Ausfall-Details abrufen](./ausfall-details-abfragen) - [Alert-Historie abrufen](./eskalation-logs-abfragen) - [Monitoring-Daten abrufen](./report-generieren) - [Ausfälle auflisten (Organisation)](./incidents-auflisten) - [PDF-Bericht herunterladen](./reports-auflisten)

### Monitoring-Standorte
URL: https://docs.uptimeify.io/de/api/monitoring-locations
Description: Ruft die Liste der Länder und Standorte ab, an denen Monitoring-Probes verfügbar sind.
Summary: ## Endpunkte - [Länder auflisten](./list-countries) — authentifiziert, nach Land gruppiert - [Öffentliche Standorte auflisten](./list-public-locations) — öffentlich, ohne Authentifizierung ## Verfügbare Standorte | Code | Name | Land | |------|------|---------| | `ch-zrh` | Zürich | Schweiz | | `cz-prg` | Prag | Tschechien | | `de-fsn` | Falkenstein | Deutschland | | `de-nbg` | Nürnberg | Deutschland | | `fi-hel` | Helsinki | Finnland | | `it-mil` | Mailand | Italien | | `pl-waw` | Warschau | Polen |

### Länder mit Standorten auflisten
URL: https://docs.uptimeify.io/de/api/monitoring-locations/list-countries
Description: Gibt Länder zurück, die Monitoring-Standorte mit aktiven Workern haben. Erfordert Authentifizierung.
Summary: `GET /api/monitoring-locations/countries` ## Beispiel (cURL) ```bash curl -X GET "$BASE_URL/api/monitoring-locations/countries" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Antwort (Response) ```json { "countries": [ { "code": "CH", "locations": 1, "workers": 6 }, { "code": "CZ", "locations": 1, "workers": 7 }, { "code": "DE", "locations": 2, "workers": 13 }, { "code": "FI", "locations": 1, "workers": 6 }, { "code": "IT", "locations": 1, "workers": 6 }, { "code": "PL", "locations": 1, "workers": 6 } ] } ```

### Öffentliche Monitoring-Standorte auflisten
URL: https://docs.uptimeify.io/de/api/monitoring-locations/list-public-locations
Description: Öffentlicher Endpunkt (keine Authentifizierung erforderlich), der alle Monitoring-Standorte mit aktiven Workern zurückgibt. Geeignet für Landingpages und Marketing.
Summary: `GET /api/public/monitoring-locations` ## Beispiel (cURL) ```bash curl -X GET "https://uptimeify.io/api/public/monitoring-locations" \ -H "Accept: application/json" ``` ## Antwort (Response) ```json { "locations": [ { "id": 14, "code": "ch-zrh", "name": "Zurich (CH)", "countryCode": "CH", "activeWorkers": 6 }, { "id": 13, "code": "cz-prg", "name": "Prague (CZ)", "countryCode": "CZ", "activeWorkers": 7 }, { "id": 8, "code": "de-fsn", "name": "Falkenstein (DE)", "countryCode": "DE", "activeWorkers": 6 }, { "id": 7, "code": "de-nbg", "name": "Nuremberg (DE)", "countryCode": "DE", "activeWorkers": 7 }, { "id": 3, "code": "fi-hel", "name": "Helsinki (FI)", "countryCode": "FI", "activeWorkers": 6 }, { "id": 6, "code": "it-mil", "name": "Milan (IT)", "countryCode": "IT", "activeWorkers": 6 }, { "id": 5, "code": "pl-waw", "name": "Warsaw (PL)", "countryCode": "PL", "activeWorkers": 6 } ] } ``` `activeWorkers` ist ein Live-Wert und schwankt über die Zeit.

### PDF-Bericht herunterladen
URL: https://docs.uptimeify.io/de/api/monitoring/download-report-pdf
Description: Lädt einen generierten PDF-Report für eine Website herunter.
Summary: `GET /api/websites/:websitePublicId/report.pdf` Du kannst entweder einen vordefinierten Zeitraum per `period` verwenden oder einen eigenen Zeitraum per `startDate`/`endDate` angeben. ## Query Parameter - `period` (optional): `last-week` | `last-month` | `last-quarter` | `last-year` (Standard: `last-month`) - `startDate` (optional, nur zusammen mit `endDate`): `YYYY-MM-DD` - `endDate` (optional, nur zusammen mit `startDate`): `YYYY-MM-DD` ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -L "$BASE_URL/api/websites/6bfec6f6-245a-47ce-843b-157d97d56f88/report.pdf?period=last-month" \ -H "Authorization: Bearer $TOKEN" \ -o report.pdf ``` ## Antwort (Response) - Content-Type: `application/pdf` - Body: PDF-Binary ## Häufige Fehler - `400 Website public ID (UUID) required` wenn `:websitePublicId` ungültig ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf die Website hast - `404 Website not found` wenn die Website nicht existiert

### Alert-Historie abrufen
URL: https://docs.uptimeify.io/de/api/monitoring/get-alert-history
Description: Gibt die letzten Benachrichtigungs-/Eskalations-Versuche (bis zu 50) für alle Incidents einer Website zurück.
Summary: `GET /api/websites/:websitePublicId/alert-history` ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/websites/6bfec6f6-245a-47ce-843b-157d97d56f88/alert-history" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Antwort (Response) ```json [ { "id": 9001, "incidentId": 501, "type": "webhook", "status": "success", "errorMessage": null, "sentAt": "2026-02-26T12:10:30.000Z", "channelName": "Slack", "channelType": "slack", "channelConfig": { "webhookUrl": "https://hooks.slack.com/..." } } ] ``` ## Häufige Fehler - `400 Website public ID (UUID) required` wenn `:websitePublicId` fehlt - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf die Website hast - `500 Failed to fetch alert history` bei Serverfehlern

### Letzte Checks abrufen
URL: https://docs.uptimeify.io/de/api/monitoring/get-check-history
Description: Gibt die letzten Monitoring-Checks einer Website zurück.
Summary: `GET /api/websites/:websitePublicId/check-history` ## Query Parameter - `limit` (optional, Standard: `50`, max: `200`) - `checkType` (optional, erlaubt u.a. `http_status`, `ssl_check`, `combined`, `playwright`, `heartbeat`, `dns` sowie Legacy-Werte wie `http` oder `ssl`) ## Pfadparameter - `websitePublicId` (empfohlen): Public-ID der Website als UUID - Legacy-Kompatibilität: numerische Website-IDs werden weiterhin akzeptiert ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/websites/6bfec6f6-245a-47ce-843b-157d97d56f88/check-history?limit=25&checkType=dns" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Antwort (Response) ```json { "data": [ { "id": "chk_01H...", "status": "success", "errorMessage": null, "warningMessage": null, "timingDns": 12, "diagnostics": null, "checkedAt": "2026-02-26T12:34:56.000Z", "locationId": 7, "locationName": "Nuremberg (DE)", "locationCode": "de-nbg" } ] } ``` ## Häufige Fehler - `400 Invalid Website identifier` wenn `:websitePublicId` weder eine gültige UUID noch eine Legacy-ID ist - `400 Invalid checkType` wenn du einen nicht unterstützten `checkType` sendest - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf die Website hast

### Ausfall-Details abrufen
URL: https://docs.uptimeify.io/de/api/monitoring/get-incident-details
Description: Gibt Details zu einem bestimmten Vorfall zurück.
Summary: `GET /api/incidents/:incidentPublicId` Enthält neben den Incident-Basisdaten auch eine Timeline (Checks/Alert-Events) sowie optional einen Evidence-Check. ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `incidentPublicId` (Path, required): Öffentliche UUID des Incidents. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/incidents/6bfec6f6-245a-47ce-843b-157d97d56f88" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` Hinweis: `evidenceCheck` kann `null` sein. `screenshotUrl` ist nur gesetzt, wenn `hasScreenshot` `true` ist. ## Antwort (Auszug) ```json { "incident": { "id": 123, "websiteId": 101, "type": "downtime", "status": "open", "startedAt": "2026-02-26T12:10:00.000Z", "resolvedAt": null, "statusCode": null, "errorMessage": "Timeout", "responseTimeMs": null }, "timeline": { "outageStartedAt": "2026-02-26T12:08:00.000Z", "outageStartedCheck": { "id": "chk_01H...", "checkedAt": "2026-02-26T12:08:00.000Z", "status": "failure", "statusCode": 503, "errorMessage": "Timeout", "responseTimeMs": null, "location": { "id": 7, "code": "de-nbg", "name": "Nuremberg (DE)" } }, "confirmationAt": "2026-02-26T12:10:00.000Z", "failedChecks": [], "failedChecksTotal": 2, "alertEvents": [ { "id": 987, "sentAt": "2026-02-26T12:11:00.000Z", "type": "email", "status": "sent", "channelName": "Ops Email", "errorMessage": null } ], "recoveryChecks": [], "recoveryChecksTotal": 0 }, "evidenceCheck": { "id": "chk_01H...", "checkedAt": "2026-02-26T12:08:00.000Z", "diagnostics": null, "hasScreenshot": false, "screenshotUrl": null } } ``` ## Häufige Fehler - `400 Incident public ID (UUID) required` wenn `:incidentPublicId` ungültig ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn der Incident existiert, du aber keinen Zugriff hast - `404 Incident not found` wenn der Incident nicht existiert

### Ausfälle auflisten
URL: https://docs.uptimeify.io/de/api/monitoring/get-incident-history
Description: Gibt die Incident-Historie einer Website zurück (letzte 100), inklusive berechneter Dauer.
Summary: `GET /api/websites/:websitePublicId/incident-history` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `websitePublicId` (Path, required): Öffentliche UUID der Website. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/websites/6bfec6f6-245a-47ce-843b-157d97d56f88/incident-history" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Antwort (Response) ```json { "incidents": [ { "id": 123, "type": "downtime", "status": "resolved", "startedAt": "Feb 26, 2026, 12:10:00", "endedAt": "Feb 26, 2026, 12:12:30", "duration": "2m 30s", "durationMs": 150000, "details": "HTTP/2 503 - Response time: 1.20s", "isOngoing": false } ], "total": 1 } ``` Hinweis: `startedAt` und `endedAt` sind formatierte Strings (serverseitig `en-US`). ## Häufige Fehler - `400 Website public ID (UUID) required` wenn `:websitePublicId` ungültig ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf die Website hast - `500 Failed to fetch incident history` bei unerwarteten Fehlern

### Monitoring-Daten abrufen
URL: https://docs.uptimeify.io/de/api/monitoring/get-monitoring-data
Description: Gibt aggregierte Timeseries-Daten für Charts zurück (Antwortzeiten, Status-Tracker, Uptime-Prozent etc.).
Summary: `GET /api/websites/:websitePublicId/monitoring-data?range=day|week|month|year` ## Query Parameter - `range` (optional): `day` | `week` | `month` | `year` (Standard: `day`) - `maxPoints` (optional): begrenzt die Anzahl an Datenpunkten (Standard: `300`, max: `2000`). Hinweis: Die API kann Datenpunkte downsamplen, um die Response klein zu halten. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/websites/6bfec6f6-245a-47ce-843b-157d97d56f88/monitoring-data?range=week" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Antwort (Response) ```json { "responseTimeData": [ { "timestamp": "2026-02-26T12:00:00.000Z", "responseTime": 123, "status": "success", "success": true, "timingDns": 12, "timingTcp": 20, "timingTls": 30, "timingTtfb": 50, "timingTransfer": 11 } ], "statusData": [ { "date": "26.02", "status": "online" } ], "uptimePercentage": "99.95", "checkSuccessRatePercentage": "99.80", "totalChecks": 100, "successfulChecks": 99 } ``` ## Häufige Fehler - `400 Website public ID (UUID) required` wenn `:websitePublicId` ungültig ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf die Website hast - `500 Failed to fetch monitoring data` bei Serverfehlern

### Metriken abrufen
URL: https://docs.uptimeify.io/de/api/monitoring/get-uptime-stats
Description: Gibt Uptime-Prozentsätze und durchschnittliche Antwortzeiten für Tag/Monat/Jahr zurück.
Summary: `GET /api/websites/:websitePublicId/uptime-stats` ## Pfadparameter - `websitePublicId` (empfohlen): Public-ID der Website als UUID - Legacy-Kompatibilität: numerische Website-IDs werden weiterhin akzeptiert ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/websites/6bfec6f6-245a-47ce-843b-157d97d56f88/uptime-stats" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Antwort (Response) ```json { "day": "100.00", "month": "99.95", "year": "99.90", "dayAvgResponse": 125, "monthAvgResponse": 118, "yearAvgResponse": 120 } ``` ## Häufige Fehler - `400 Invalid Website identifier` wenn `:websitePublicId` weder eine gültige UUID noch eine Legacy-ID ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf die Website hast

### Ausfälle auflisten (Organisation)
URL: https://docs.uptimeify.io/de/api/monitoring/list-incidents
Description: Listet Incidents für eine Organisation auf. Die Daten sind durch deine Session/Permissions eingeschränkt.
Summary: `GET /api/incidents?organizationId=:organizationId` Readonly-User sehen nur Incidents für Kunden, denen sie zugewiesen sind. ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Query Parameter - `organizationId` (optional): Wenn nicht gesetzt, wird die `organizationId` aus deiner Session verwendet. - `limit` (optional, Standard: `100`, max: `500`): Maximale Anzahl an Incidents. - `offset` (optional, Standard: `0`): Pagination-Offset. - `includeTotal` (optional, Standard: `0`): Wenn `1` (oder `true`), enthält die Response zusätzlich `total`, `limit` und `offset`. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/incidents?organizationId=1" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` Pagination: ```bash curl -X GET "$BASE_URL/api/incidents?organizationId=1&limit=100&offset=0" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Antwort (Auszug) ```json [ { "id": 123, "websiteId": 101, "status": "open", "severity": "downtime", "started_at": "2026-02-26T12:10:00.000Z", "resolved_at": null, "last_notified_at": "2026-02-26T12:11:00.000Z", "error_message": "Timeout", "status_code": null, "response_time_ms": null, "website": { "id": 101, "name": "Main Marketing Site", "url": "https://example.com", "status": "active" }, "customer": { "id": 12, "email": "ops@example.com", "company": "Acme Corp" } } ] ``` Wenn `includeTotal=1`, ändert sich das Response-Format zu: ```json { "incidents": [], "total": 1234, "limit": 100, "offset": 0 } ``` ## Häufige Fehler - `400 Organization ID is required` wenn keine Organisation ermittelt werden kann - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keine Leserechte für die Organisation hast - `500 Failed to fetch incidents` bei unerwarteten Fehlern

### Monitore
URL: https://docs.uptimeify.io/de/api/monitors
Description: Verwalte Protokoll-Monitore (ICMP, SMTP, SSH, FTP, IMAP/POP).
Summary: Detail-/Update-/Delete-/Check-Endpunkte für Protokoll-Monitore verwenden monitor-spezifische `publicId`-UUIDs im Pfad. ## Ressourcen - [ICMP Monitore](./icmp-monitore/index) - [SMTP Monitore](./smtp-monitore/index) - [SSH Monitore](./ssh-monitore/index) - [FTP Monitore](./ftp-monitore/index) - [IMAP/POP Monitore](./imap-pop-monitore/index) - [DNS Monitore](./dns-monitore/index) - [DNSBL-Überwachung (Kunden-IPs)](./dnsbl-ueberwachung/index) - [Domain-Ablauf-Überwachung (Kunden-Domains)](./domain-ablauf-ueberwachung/index)

### DNS Monitore
URL: https://docs.uptimeify.io/de/api/monitors/dns-monitors
Description: Verwalte DNS-Monitore, die DNS-Auflösung/Records für einen Hostnamen prüfen.
Summary: Pfadbasierte DNS-Monitor-Endpunkte verwenden `dnsMonitorPublicId`-UUIDs. ## Endpunkte - [DNS Monitore auflisten](./dns-monitore-auflisten) - [DNS Monitor erstellen](./dns-monitor-erstellen) - [DNS Monitor abrufen](./dns-monitor-abrufen) - [DNS Monitor aktualisieren](./dns-monitor-aktualisieren-status) - [DNS Monitor löschen](./dns-monitor-loeschen) - [DNS Check triggern](./dns-monitor-check-triggern) - [DNS Monitor Check-Historie abrufen](./dns-monitor-check-historie-abrufen)

### DNS Monitor erstellen
URL: https://docs.uptimeify.io/de/api/monitors/dns-monitors/create-dns-monitor
Description: Erstellt einen neuen DNS-Monitor für einen Kunden.
Summary: `POST /api/dns-monitors` ## Anfrage (Request Body) ```json { "customerId": "6bfec6f6-245a-47ce-843b-157d97d56f88", "name": "Example DNS", "hostname": "example.com", "status": "active", "checkInterval": 30, "timeoutSeconds": 30, "dnsConfig": { "rrtypes": ["A", "AAAA"], "matchMode": "exact", "expectedValues": { "A": ["93.184.216.34"], "AAAA": ["2606:2800:220:1:248:1893:25c8:1946"] }, "triggerOn": { "resolveError": true, "mismatch": true } } } ``` Hinweise: - `customerId`, `name`, `hostname`, `dnsConfig.rrtypes`, `dnsConfig.matchMode` und `dnsConfig.expectedValues` sind erforderlich. - `customerId` akzeptiert entweder die interne numerische ID oder die `publicId`-UUID des Kunden. - Global Supporter und Readonly-User dürfen keine DNS-Monitore erstellen. - `hostname` muss ein Hostname sein (kein Protokoll, kein Pfad). - `dnsConfig.expectedValues` muss für jeden RR-Type aus `dnsConfig.rrtypes` mindestens einen erwarteten Wert enthalten. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X POST \ "$BASE_URL/api/dns-monitors" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"customerId":"6bfec6f6-245a-47ce-843b-157d97d56f88","name":"Example DNS","hostname":"example.com","dnsConfig":{"rrtypes":["A"],"matchMode":"exact","expectedValues":{"A":["93.184.216.34"]},"triggerOn":{"resolveError":true,"mismatch":true}}}' ``` ## Häufige Fehler - `400 Invalid Customer identifier` - `400 hostname must be a valid hostname (no protocol, no path)` - `400 Expected values are required for RR type <TYPE>` - `401 Unauthorized` - `403 Forbidden` (Readonly/Global Supporter oder kein Zugriff) - `404 Customer not found` ## Antwort (Response) Gibt das erstellte DNS-Monitor-Objekt zurück. Siehe [Fehlerliste](/de/api/error-codes-and-known-pitfalls) für Fehlerantworten.

### DNS Monitor löschen
URL: https://docs.uptimeify.io/de/api/monitors/dns-monitors/delete-dns-monitor
Description: Löscht einen DNS-Monitor.
Summary: `DELETE /api/dns-monitors/:dnsMonitorPublicId` ## Antwort (Response) Gibt `204 No Content` zurück. Siehe [Fehlerliste](/de/api/error-codes-and-known-pitfalls) für Fehlerantworten.

### DNS Monitor abrufen
URL: https://docs.uptimeify.io/de/api/monitors/dns-monitors/get-dns-monitor
Description: Gibt einen einzelnen DNS-Monitor zurück.
Summary: `GET /api/dns-monitors/:dnsMonitorPublicId` Die Response enthält nur den DNS-Monitor selbst und bettet keinen vollständigen Kunden-Datensatz ein. ## Beispiel-Response ```json { "id": 1, "publicId": "3c741f27-7015-4202-93ea-0f97cc6bc769", "organizationId": 2, "customerId": 2, "customerName": "Zaskoku & Haupt GbR", "name": "haupt.design", "hostname": "haupt.design", "checkInterval": 30, "timeoutSeconds": 30, "dnsConfig": { "rrtypes": ["A"], "matchMode": "exact", "triggerOn": { "mismatch": true, "resolveError": true }, "expectedValues": { "A": ["76.76.21.21"] } }, "status": "active", "notificationPhoneNumber": null, "notificationEmail": null, "lastCheckedAt": "2026-04-03T14:55:00.005Z", "createdAt": "2026-02-23T20:24:54.731Z", "updatedAt": "2026-04-03T14:55:01.193Z" } ```

### DNS Monitor Alert-Historie abrufen
URL: https://docs.uptimeify.io/de/api/monitors/dns-monitors/get-dns-monitor-alert-history
Description: Gibt die Benachrichtigungs-/Eskalationsversuche (Alert-Historie) für Vorfälle eines DNS Monitors zurück.
Summary: `GET /api/dns-monitors/:dnsMonitorPublicId/alert-history` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `dnsMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des DNS Monitors. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/dns-monitors/11111111-1111-4111-8111-111111111111/alert-history" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Beispiel-Antwort ```json { "alerts": [ { "id": 987, "incidentId": 123, "type": "slack", "status": "sent", "channelName": "Ops Slack", "sentAt": "2026-02-26T12:11:00.000Z", "errorMessage": null } ], "total": 1 } ``` Jeder Eintrag ist ein Zustellversuch an einen Benachrichtigungskanal. `status` ist `sent` oder `failed` (bei Fehler ist `errorMessage` gesetzt); `type` ist der Kanaltyp (z. B. `email`, `slack`, `opsgenie`). ## Häufige Fehler - `400 DNS monitor public ID (UUID) required` wenn `:dnsMonitorPublicId` ungültig ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf den Monitor hast

### DNS Monitor Check-Historie abrufen
URL: https://docs.uptimeify.io/de/api/monitors/dns-monitors/get-dns-monitor-check-history
Description: Gibt die letzten DNS-Check-Ergebnisse zurück.
Summary: `GET /api/dns-monitors/:dnsMonitorPublicId/check-history` ## Antwort (Response) Gibt eine Liste von Check-Einträgen zurück. Siehe [Fehlerliste](/de/api/error-codes-and-known-pitfalls) für Fehlerantworten.

### DNS Monitor Ausfall-Historie abrufen
URL: https://docs.uptimeify.io/de/api/monitors/dns-monitors/get-dns-monitor-incident-history
Description: Gibt die Vorfälle eines einzelnen DNS Monitors zurück (die letzten 100), inklusive berechneter Dauer.
Summary: `GET /api/dns-monitors/:dnsMonitorPublicId/incident-history` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `dnsMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des DNS Monitors. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/dns-monitors/11111111-1111-4111-8111-111111111111/incident-history" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Beispiel-Antwort ```json { "incidents": [ { "id": 123, "type": "downtime", "status": "resolved", "startedAt": "Feb 26, 2026, 12:10:00", "endedAt": "Feb 26, 2026, 12:12:30", "duration": "2m 30s" } ], "total": 1 } ``` `type` spiegelt die Fehlerkategorie dieses Monitors wider; `status` ist `active` (laufend) oder `resolved`. Laufende Vorfälle haben ein `null` bei `endedAt`. ## Häufige Fehler - `400 DNS monitor public ID (UUID) required` wenn `:dnsMonitorPublicId` ungültig ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf den Monitor hast

### DNS Monitore auflisten
URL: https://docs.uptimeify.io/de/api/monitors/dns-monitors/list-dns-monitors
Description: Listet DNS-Monitore einer Organisation (mit Pagination) auf.
Summary: `GET /api/dns-monitors` Jedes Item enthält nur den DNS-Monitor selbst und bettet keinen vollständigen Kunden-Datensatz ein. ## Query Parameter - `organizationId` (optional): Standard ist deine Session-Organisation - `customerId` (optional) - `search` (optional) - `page` (optional, Default `1`) - `perPage` (optional, Default `50`, max `200`) ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET \ "$BASE_URL/api/dns-monitors?organizationId=1&page=1&perPage=50" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Beispiel-Antwort ```json { "items": [ { "id": 5, "publicId": "79fbe9b0-f9c6-4026-86de-1dbebc84d9bb", "organizationId": 2, "customerId": 2, "customerName": "Zaskoku & Haupt GbR", "name": "Primary DNS Monitor", "hostname": "claas.sh", "checkInterval": 30, "timeoutSeconds": 30, "dnsConfig": {}, "allowedCheckCountryCodes": null, "status": "active", "notificationPhoneNumber": null, "notificationEmail": null, "lastCheckedAt": "2026-04-03T14:54:56.561Z", "createdAt": "2026-04-03T14:54:56.383Z", "updatedAt": "2026-04-03T14:54:56.740Z" } ], "total": 0, "page": 1, "perPage": 50 } ``` "total": 0, "page": 1, "perPage": 50 } ```

### DNS Check triggern
URL: https://docs.uptimeify.io/de/api/monitors/dns-monitors/trigger-check-dns-monitor
Description: Triggert einen sofortigen DNS-Check über alle eligible Monitoring-Locations.
Summary: `POST /api/dns-monitors/:dnsMonitorPublicId/trigger-check` ## Antwort (Response) Gibt `202 Accepted` zurück, wenn der Check erfolgreich angestoßen wurde. Siehe [Fehlerliste](/de/api/error-codes-and-known-pitfalls) für Fehlerantworten.

### DNS Monitor aktualisieren
URL: https://docs.uptimeify.io/de/api/monitors/dns-monitors/update-dns-monitor
Description: Aktualisiert einen DNS-Monitor.
Summary: `PATCH /api/dns-monitors/:dnsMonitorPublicId` Hinweise: - Readonly-User dürfen nur `status` ändern. - Global Supporter dürfen nicht mutieren. - Wenn du `customerId` mitsendest, akzeptiert das Feld entweder die interne numerische ID oder die `publicId`-UUID des Kunden. ## Request Body (Beispiel) ```json { "customerId": "6764e84f-f02a-43e6-a46d-cecaec556723", "status": "maintenance", "name": "Primary DNS Monitor", "hostname": "claas.sh", "checkInterval": 30, "timeoutSeconds": 30, "dnsConfig": { "rrtypes": ["A"], "matchMode": "exact", "expectedValues": { "A": ["76.76.21.21"] }, "triggerOn": { "resolveError": true, "mismatch": true } } } ``` Wenn du `dnsConfig` mitsendest, muss es `rrtypes`, `matchMode` und für jeden RR-Type in `rrtypes` mindestens einen Eintrag in `expectedValues` enthalten. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X PATCH \ "$BASE_URL/api/dns-monitors/11111111-1111-4111-8111-111111111111" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"customerId":"6764e84f-f02a-43e6-a46d-cecaec556723","status":"maintenance","name":"Primary DNS Monitor","hostname":"claas.sh","checkInterval":30,"timeoutSeconds":30,"dnsConfig":{"rrtypes":["A"],"matchMode":"exact","expectedValues":{"A":["76.76.21.21"]},"triggerOn":{"resolveError":true,"mismatch":true}}}' ``` ## Häufige Fehler - `400 DNS monitor ID is required` - `400 Invalid status` - `400 Invalid Customer identifier` - `400 Expected values are required for RR type <TYPE>` - `401 Unauthorized` - `403 Forbidden` - `404 Customer not found` ## Antwort (Response) Gibt das aktualisierte DNS-Monitor-Objekt zurück. Siehe [Fehlerliste](/de/api/error-codes-and-known-pitfalls) für Fehlerantworten.

### DNSBL-Überwachung (Kunden-IPs)
URL: https://docs.uptimeify.io/de/api/monitors/dnsbl-monitoring
Description: DNSBL-Überwachung wird über Kunden-IPs konfiguriert. Diese IPs werden periodisch gegen DNS-basierte Blacklists geprüft.
Summary: ## Endpunkte - [Kunden-IPs (Organisation) auflisten](./kunden-ips-auflisten) - [Kunden-IP abrufen](./kunden-ip-abrufen) - [Kunden-IP aktualisieren](./kunden-ip-aktualisieren) - [Kunden-IP löschen](./kunden-ip-loeschen) - [Kunden-IPs (Kunde) auflisten](./kunden-ips-fuer-kunden-auflisten) - [Kunden-IP (für Kunde) erstellen](./kunden-ip-fuer-kunden-erstellen)

### Create Customer Ip For Customer
URL: https://docs.uptimeify.io/de/api/monitors/dnsbl-monitoring/create-customer-ip-for-customer
Summary: title: Kunden-IP (für Kunde) erstellen description: POST /api/customers/:customerPublicId/ips --- # Kunden-IP (für Kunde) erstellen `POST /api/customers/:customerPublicId/ips` Erstellt eine neue Kunden-IP für DNSBL-Überwachung. ## Anfrage (Request Body) ```json { "ipAddress": "203.0.113.10", "label": "Mail Server", "ipFamily": "v4", "status": "active" } ``` Hinweise: - `customerPublicId` sollte die Public-ID des Kunden als UUID sein. Legacy-numerische Kunden-IDs bleiben aus Kompatibilitätsgründen weiter unterstützt. - `ipFamily` ist optional (wird sonst aus der IP abgeleitet). - Wenn `ipFamily` gesetzt ist, muss es zur IP-Version passen. - Das Erstellen einer `active` IP kann wegen Quota-Limits abgelehnt werden. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X POST "$BASE_URL/api/customers/6bfec6f6-245a-47ce-843b-157d97d56f88/ips" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"ipAddress":"203.0.113.10","label":"Mail Server","status":"active"}' ``` ## Häufige Fehler - `400 Invalid Customer identifier` wenn `:customerPublicId` fehlt/ungültig ist - `400 Invalid IP address` wenn `ipAddress` ungültig ist - `400 IP family mismatch...` wenn `ipFamily` nicht zur IP passt - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` für Readonly/Global-Supporter oder bei fehlendem Zugriff - `403 Active IP limit reached...` wenn Erstellung/Aktivierung dein Quota überschreitet - `404 Customer not found` wenn der Kunde nicht existiert - `409 IP already exists for this customer` wenn die IP bereits existiert ## Antwort (Response) Gibt das erstellte Kunden-IP-Objekt zurück. Siehe [Fehlerliste](/de/api/error-codes-and-known-pitfalls) für Fehlerantworten.

### Kunden-IP löschen
URL: https://docs.uptimeify.io/de/api/monitors/dnsbl-monitoring/delete-customer-ip
Description: Löscht eine Kunden-IP.
Summary: `DELETE /api/customer-ips/:customerIpPublicId` Hinweis: - Readonly-User und Global Supporter dürfen nicht löschen. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X DELETE "$BASE_URL/api/customer-ips/11111111-1111-4111-8111-111111111111" \ -H "Authorization: Bearer $TOKEN" ``` ## Beispiel-Antwort ```json { "success": true } ``` ## Häufige Fehler - `400 Invalid IP identifier` wenn `:customerIpPublicId` weder UUID noch Legacy-ID ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` für Readonly/Global-Supporter oder bei fehlendem Zugriff - `404 IP not found` wenn die IP nicht existiert

### Kunden-IP abrufen
URL: https://docs.uptimeify.io/de/api/monitors/dnsbl-monitoring/get-customer-ip
Description: Gibt eine Kunden-IP inkl. DNSBL-Status zurück (falls vorhanden).
Summary: `GET /api/customer-ips/:customerIpPublicId` Die Response enthält die Kunden-IP selbst und, falls vorhanden, ein `dnsbl`-Objekt. Ein vollständiger Kunden-Datensatz wird nicht eingebettet. ## Beispiel-Response ```json { "id": 1, "publicId": "a19effb9-eb5f-459b-b5d6-2f615b574651", "customerId": 2, "customerName": "Zaskoku & Haupt GbR", "label": "Kurbelix Adminserver", "ipAddress": "77.75.254.185", "ipFamily": "v4", "status": "active", "createdAt": "2026-02-03T15:06:46.469Z", "updatedAt": "2026-02-03T15:06:46.469Z", "dnsbl": { "isListed": true, "listedCount": 1, "listings": [ { "name": "all.s5h.net", "reason": "Listed in all.s5h.net", "listKey": "all.s5h.net", "delistUrl": "http://s5h.net", "resultCode": "127.0.0.2" } ], "lastError": null, "lastCheckedAt": "2026-04-03T15:13:00.083Z", "lastChangedAt": "2026-02-04T10:00:00.121Z", "lastListedAt": "2026-04-03T15:13:00.083Z", "lastCleanAt": null, "lastNotifiedListedAt": "2026-04-02T20:55:04.969Z", "lastNotifiedCleanAt": null } } ``` ## Pfadparameter - `customerIpPublicId` (empfohlen): Public-ID der Kunden-IP als UUID - Legacy-Kompatibilität: numerische IDs werden weiterhin akzeptiert ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/customer-ips/11111111-1111-4111-8111-111111111111" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Häufige Fehler - `400 Invalid IP identifier` wenn `:customerIpPublicId` weder UUID noch Legacy-ID ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf den Kunden hast - `404 IP not found` wenn die IP nicht existiert

### Kunden-IPs (Organisation) auflisten
URL: https://docs.uptimeify.io/de/api/monitors/dnsbl-monitoring/list-customer-ips
Description: Listet Kunden-IPs innerhalb einer Organisation auf (Pagination + Suche). Das ist die primäre Konfiguration für DNSBL-Überwachung.
Summary: `GET /api/customer-ips` ## Query Parameter - `organizationId` (optional): Standard ist deine Session-Organisation - `customerId` (optional): akzeptiert die Public-ID des Kunden als UUID (empfohlen) oder eine Legacy-numerische Kunden-ID - `search` (optional) - `page` (optional, Default `1`) - `perPage` (optional, Default `50`, max `200`) Optional bedeutet hier: Parameter komplett weglassen, wenn du sie nicht nutzt. Sende keine leeren Strings wie `page=` oder `perPage=`. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/customer-ips?organizationId=1&page=1&perPage=50" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Beispiel-Antwort ```json { "items": [], "total": 0, "page": 1, "perPage": 50 } ``` ## Häufige Fehler - `400 Organization ID required` wenn keine Organisation abgeleitet werden kann - `400` Query-Validierungsfehler (z.B. ungültige `organizationId`, `customerId`, `page`, `perPage`) - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf die Organisation hast

### List Customer Ips For Customer
URL: https://docs.uptimeify.io/de/api/monitors/dnsbl-monitoring/list-customer-ips-for-customer
Summary: title: Kunden-IPs (Kunde) auflisten description: GET /api/customers/:customerPublicId/ips --- # Kunden-IPs (Kunde) auflisten `GET /api/customers/:customerPublicId/ips` Listet IPs eines Kunden inkl. DNSBL-Status auf. ## Pfadparameter - `customerPublicId` (empfohlen): Public-ID des Kunden als UUID - Legacy-Kompatibilität: numerische Kunden-IDs werden weiterhin akzeptiert ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/customers/6bfec6f6-245a-47ce-843b-157d97d56f88/ips" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Häufige Fehler - `400 Invalid Customer identifier` wenn `:customerPublicId` fehlt/ungültig ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf den Kunden hast - `404 Customer not found` wenn der Kunde nicht existiert ## Antwort (Response) Gibt eine Liste von Kunden-IP-Objekten zurück. Siehe [Fehlerliste](/de/api/error-codes-and-known-pitfalls) für Fehlerantworten.

### Kunden-IP aktualisieren
URL: https://docs.uptimeify.io/de/api/monitors/dnsbl-monitoring/update-customer-ip
Description: Aktualisiert eine Kunden-IP (z.B. Label oder Status).
Summary: `PATCH /api/customer-ips/:customerIpPublicId` Hinweise: - Readonly-User und Global Supporter dürfen nicht mutieren. - Aktivieren kann wegen Quota-Limits abgelehnt werden. ## Anfrage (Request Body) ```json { "label": "Mail Server", "status": "active" } ``` ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X PATCH "$BASE_URL/api/customer-ips/11111111-1111-4111-8111-111111111111" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"label":"Mail Server","status":"active"}' ``` ## Häufige Fehler - `400 Invalid IP identifier` wenn `:customerIpPublicId` weder UUID noch Legacy-ID ist - `400` Body-Validierungsfehler (z.B. ungültiger `status`) - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` für Readonly/Global-Supporter oder bei fehlendem Zugriff - `403 Active IP limit reached...` wenn Aktivierung dein Quota überschreitet - `404 IP not found` wenn die IP nicht existiert ## Antwort (Response) Gibt das aktualisierte Kunden-IP-Objekt zurück. Siehe [Fehlerliste](/de/api/error-codes-and-known-pitfalls) für Fehlerantworten.

### Domain-Ablauf-Überwachung (Kunden-Domains)
URL: https://docs.uptimeify.io/de/api/monitors/domain-expiry-monitoring
Description: Die Domain-Ablauf-Überwachung wird über Kunden-Domains konfiguriert.
Summary: ## Endpunkte - [Kunden-Domain (für Kunde) erstellen](./kunden-domain-fuer-kunden-erstellen) - [Kunden-Domains (Organisation) auflisten](./kunden-domains-auflisten) - [Kunden-Domain abrufen](./kunden-domain-abrufen) - [Kunden-Domain aktualisieren](./kunden-domain-aktualisieren) - [Kunden-Domain löschen](./kunden-domain-loeschen) - [Domain-Ablauf (Websites) auflisten](./domain-ablauf-websites-auflisten)

### Create Customer Domain
URL: https://docs.uptimeify.io/de/api/monitors/domain-expiry-monitoring/create-customer-domain
Summary: title: Kunden-Domain erstellen (Kunde) description: POST /api/customers/:customerPublicId/domains --- # Kunden-Domain erstellen (Kunde) `POST /api/customers/:customerPublicId/domains` Erstellt eine Kunden-Domain für die Ablauf-Überwachung. ## Request Body ```json { "domainName": "example.com", "label": "Main Domain", "status": "active", "expiryWarningDays": 30, "expiryErrorDays": 7 } ``` Hinweise: - `customerPublicId` sollte die Public-ID des Kunden als UUID sein. Legacy-numerische Kunden-IDs bleiben aus Kompatibilitätsgründen weiter unterstützt. - `domainName` muss eine gültige Domain wie `example.com` sein (kein Protokoll, kein Pfad). - Das Erstellen einer `active` Domain kann durch Quota-Limits blockiert werden. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X POST "$BASE_URL/api/customers/6bfec6f6-245a-47ce-843b-157d97d56f88/domains" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"domainName":"example.com","label":"Main Domain","status":"active","expiryWarningDays":30,"expiryErrorDays":7}' ``` ## Antwort Gibt den neu erstellten Kunden-Domain-Record zurück. ## Häufige Fehler - `400 Invalid Customer identifier` wenn `:customerPublicId` fehlt/ungültig ist - `400 Invalid domain name...` wenn `domainName` ungültig ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` für Readonly/Global-Supporter-User, oder wenn du keinen Zugriff auf den Kunden hast - `403 Active domain limit reached...` wenn das Erstellen/Aktivieren dein Quota-Limit überschreiten würde - `404 Customer not found` wenn der Kunde nicht existiert

### Kunden-Domain löschen
URL: https://docs.uptimeify.io/de/api/monitors/domain-expiry-monitoring/delete-customer-domain
Description: Löscht eine Kunden-Domain.
Summary: `DELETE /api/customer-domains/:customerDomainPublicId` Hinweise: - Readonly-User und Global-Supporter können Kunden-Domains nicht löschen. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X DELETE "$BASE_URL/api/customer-domains/22222222-2222-4222-8222-222222222222" \ -H "Authorization: Bearer $TOKEN" ``` ## Beispiel-Antwort ```json { "success": true } ``` ## Häufige Fehler - `400 Invalid Domain identifier` wenn `:customerDomainPublicId` weder UUID noch Legacy-ID ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` für Readonly/Global-Supporter-User, oder wenn du keinen Zugriff auf die Domain/den Kunden hast - `404 Domain not found` wenn die Domain nicht existiert

### Kunden-Domain abrufen
URL: https://docs.uptimeify.io/de/api/monitors/domain-expiry-monitoring/get-customer-domain
Description: Gibt eine einzelne Kunden-Domain zurück.
Summary: `GET /api/customer-domains/:customerDomainPublicId` Die Response enthält die Kunden-Domain selbst und bettet keinen vollständigen Kunden-Datensatz ein. ## Pfadparameter - `customerDomainPublicId` (empfohlen): Public-ID der Kunden-Domain als UUID - Legacy-Kompatibilität: numerische IDs werden weiterhin akzeptiert Hinweise: - Einige Registries/TLDs (z.B. `.de`) veröffentlichen kein Ablaufdatum via RDAP. In diesem Fall kann `expiry.domainExpiresAt` `null` sein und `expiry.lastError` enthält ggf. eine erklärende Fehlermeldung. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/customer-domains/22222222-2222-4222-8222-222222222222" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Beispiel-Response ```json { "id": 20, "publicId": "d70884d9-4cef-4fe5-9b15-341b7dd9e196", "customerId": 2, "customerName": "Zaskoku & Haupt GbR", "label": "Primary Domain", "domainName": "cacheassist.io", "status": "active", "expiryWarningDays": 30, "expiryErrorDays": 7, "createdAt": "2026-04-03T15:28:40.602Z", "updatedAt": "2026-04-03T15:28:40.602Z", "expiry": { "domainExpiresAt": null, "domainRegistrar": null, "isExpired": false, "lastError": "RDAP query error for cacheassist.io: fetch failed", "lastCheckedAt": "2026-04-03T15:29:00.200Z", "lastChangedAt": null, "lastNotifiedWarningAt": null, "lastNotifiedErrorAt": null, "lastNotifiedExpiredAt": null } } ``` ## Häufige Fehler - `400 Invalid Domain identifier` wenn `:customerDomainPublicId` fehlt/ungültig ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf die Domain/den Kunden hast - `404 Domain not found` wenn die Domain nicht existiert

### Kunden-Domains (Organisation) auflisten
URL: https://docs.uptimeify.io/de/api/monitors/domain-expiry-monitoring/list-customer-domains
Description: Listet Kunden-Domains innerhalb einer Organisation auf (Pagination + Suche).
Summary: `GET /api/customer-domains` ## Query Parameter - `organizationId` (optional): Standard ist deine Session-Organisation - `customerId` (optional): akzeptiert die Public-ID des Kunden als UUID (empfohlen) oder eine Legacy-numerische Kunden-ID - `search` (optional) - `page` (optional, Default `1`) - `perPage` (optional, Default `50`, max `200`) Optional bedeutet hier: Parameter komplett weglassen, wenn du sie nicht nutzt. Sende keine leeren Strings wie `page=` oder `perPage=`. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/customer-domains?organizationId=1&page=1&perPage=50" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Antwort Gibt eine paginierte Antwort zurück: ```json { "items": [ { "id": 1, "publicId": "34eb0ec1-315d-45c4-aefe-0e5d12b11183", "customerId": 2, "customerName": "Zaskoku & Haupt GbR", "customerPublicId": "6764e84f-f02a-43e6-a46d-cecaec556723", "label": null, "domainName": "digitalduett.com", "status": "active", "expiryWarningDays": 30, "expiryErrorDays": 7, "createdAt": "2026-02-13T21:21:03.001Z", "updatedAt": "2026-02-13T21:21:03.001Z", "expiry": { "domainExpiresAt": "2026-12-20T20:44:45.000Z", "domainRegistrar": "NameCheap, Inc.", "isExpired": false, "lastError": null, "lastCheckedAt": "2026-04-03T10:59:00.321Z", "lastChangedAt": "2026-04-03T10:59:00.321Z", "lastNotifiedWarningAt": null, "lastNotifiedErrorAt": null, "lastNotifiedExpiredAt": null } } ], "total": 0, "page": 1, "perPage": 50 } ``` Jedes Item enthält flache Kundenfelder plus ein `expiry`-Objekt (oder `null`). ## Häufige Fehler - `400 Organization ID required` wenn keine Organisation abgeleitet werden kann - `400` Query-Validierungsfehler (z.B. ungültige `organizationId`, `customerId`, `page`, `perPage`) - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf die Organisation hast

### Domain-Ablauf (Websites) auflisten
URL: https://docs.uptimeify.io/de/api/monitors/domain-expiry-monitoring/list-domain-expiry-websites
Description: Listet Websites mit den zuletzt bekannten Informationen zum Domain-Ablaufdatum auf.
Summary: `GET /api/domains` ## Query Parameter - `organizationId` (optional): Standard ist deine Session-Organisation - `customerId` (optional) - `search` (optional) - `page` (optional, Default `1`) - `perPage` (optional, Default `50`, max `200`) ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/domains?organizationId=1&page=1&perPage=50" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Antwort ```json { "items": [ { "id": 101, "name": "Example Website", "url": "https://example.com", "status": "active", "customerId": 10, "customerName": "Example Customer", "checkDomainExpiryEnabled": true, "domainExpiryNoticeDays": 30, "domainExpiryErrorDays": 7, "domainExpiresAt": "2026-12-31T00:00:00.000Z", "domainRegistrar": "Example Registrar", "lastDomainCheckAt": "2026-03-03T10:00:00.000Z", "daysUntilExpiry": 303, "expiryStatus": "ok" } ], "total": 1, "page": 1, "perPage": 50 } ``` ## Feldnotizen - `expiryStatus` kann sein: `ok`, `warning`, `critical`, `expired`, `unknown`, `disabled`. - `daysUntilExpiry` ist `null`, wenn kein Ablaufdatum verfügbar ist. ## Häufige Fehler - `400 Organization ID required` wenn keine Organisation abgeleitet werden kann - `400 Invalid customerId` wenn `customerId` ungültig ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf die Organisation hast

### Kunden-Domain aktualisieren
URL: https://docs.uptimeify.io/de/api/monitors/domain-expiry-monitoring/update-customer-domain
Description: Aktualisiert eine Kunden-Domain (z.B. Label, Status, Ablauf-Schwellenwerte).
Summary: `PATCH /api/customer-domains/:customerDomainPublicId` Hinweise: - Readonly-User und Global-Supporter können Kunden-Domains nicht aktualisieren. - Das Aktivieren einer deaktivierten Domain kann abgelehnt werden, wenn Quota-Limits erreicht sind. ## Request Body ```json { "label": "Main Domain", "status": "active", "expiryWarningDays": 30, "expiryErrorDays": 7 } ``` ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X PATCH "$BASE_URL/api/customer-domains/22222222-2222-4222-8222-222222222222" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"status":"active"}' ``` ## Antwort Gibt den aktualisierten Kunden-Domain-Record zurück. ## Häufige Fehler - `400` Body-Validierungsfehler (z.B. ungültige Thresholds) - `400 Invalid Domain identifier` wenn `:customerDomainPublicId` weder UUID noch Legacy-ID ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` für Readonly/Global-Supporter-User, oder wenn du keinen Zugriff auf die Domain/den Kunden hast - `403 Active domain limit reached...` wenn das Aktivieren dein Quota-Limit überschreiten würde - `404 Domain not found` wenn die Domain nicht existiert

### FTP Monitore
URL: https://docs.uptimeify.io/de/api/monitors/ftp-monitors
Description: Verwalte FTP Monitore.
Summary: Pfadbasierte FTP-Monitor-Endpunkte verwenden `ftpMonitorPublicId`-UUIDs. ## Endpunkte - [FTP Monitore auflisten](./ftp-monitore-auflisten) - [FTP Monitor erstellen](./ftp-monitor-erstellen) - [FTP Monitor abrufen](./ftp-monitor-abrufen) - [FTP Monitor Details abrufen](./ftp-monitor-details-abrufen) - [FTP Monitor Check-Historie abrufen](./ftp-monitor-check-historie-abrufen) - [FTP Monitor aktualisieren (Status ändern)](./ftp-monitor-aktualisieren-status) - [FTP Monitor löschen](./ftp-monitor-loeschen) - [FTP Check triggern](./ftp-monitor-check-triggern)

### FTP Monitor erstellen
URL: https://docs.uptimeify.io/de/api/monitors/ftp-monitors/create-ftp-monitor
Description: Erstellt einen neuen FTP Monitor.
Summary: `POST /api/ftp-monitors` ## Authentifizierung Dieser Endpoint benötigt ein API-Token: `Authorization: Bearer <token>` ## Request Body - `customerId` (required, number | string): interne numerische Kunden-ID oder Customer-`publicId`-UUID - `name` (required, string) - `hostname` (required, string): Muss ein Hostname sein (kein Protokoll, kein Pfad). - `port` (optional, number | null): Wenn weggelassen/null, nutzt der Worker einen Default-Port. - `status` (optional): `active`, `maintenance`, `disabled` (akzeptiert auch `inactive` und normalisiert zu `disabled`) - `checkInterval` (optional, number): Minuten (min: 1, max: 60) - `timeoutSeconds` (optional, number): Sekunden (min: 1, max: 60) - `ftpConfig` (optional, object): FTP-Verbindungsoptionen (als JSON gespeichert) ### `ftpConfig` Der Monitoring-Worker liest diese Keys: - `user` (optional, string): Default `anonymous` - `password` (optional, string): Default `anonymous@` - `secure` (optional, boolean | `"implicit"`): - `false` (Default): plain FTP - `true`: explicit TLS - `"implicit"`: implicit TLS (Worker nutzt default Port `990`, wenn `port` nicht gesetzt ist) ```json { "customerId": "6764e84f-f02a-43e6-a46d-cecaec556723", "name": "FTP Availability", "hostname": "claas.sh", "port": 21, "status": "active", "checkInterval": 5, "timeoutSeconds": 30, "ftpConfig": { "user": "root", "password": "exampleRoot", "secure": "explicit" } } ``` ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<your-api-token>" curl -X POST \ "$BASE_URL/api/ftp-monitors" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"customerId":"6764e84f-f02a-43e6-a46d-cecaec556723","name":"FTP Availability","hostname":"claas.sh","port":21,"status":"active","checkInterval":5,"timeoutSeconds":30,"ftpConfig":{"user":"root","password":"exampleRoot","secure":"explicit"}}' ``` ## Response ```json { "id": 400, "organizationId": 1, "customerId": 2, "name": "FTP Availability", "hostname": "claas.sh", "port": 21, "status": "active", "checkInterval": 5, "timeoutSeconds": 30, "allowedCheckCountryCodes": null, "notificationPhoneNumber": null, "notificationEmail": null, "lastCheckedAt": null, "createdAt": "2026-02-25T10:00:00.000Z", "updatedAt": "2026-02-25T10:00:00.000Z", "config": { "user": "root", "password": "exampleRoot", "secure": "explicit" }, "ftpConfig": { "user": "root", "password": "exampleRoot", "secure": "explicit" } } ``` ## Häufige Fehler - `400 Invalid Customer identifier` wenn `customerId` weder gültige UUID noch Legacy-ID ist - `400 hostname must be a valid hostname (no protocol, no path)` bei ungültigem Hostname - `401 Unauthorized` wenn du nicht authentifiziert bist - `403 Forbidden` wenn du keinen Zugriff hast oder keine Monitore erstellen darfst (z.B. Read-only oder Global Supporter) - `404 Customer not found` wenn `customerId` nicht existiert

### FTP Monitor löschen
URL: https://docs.uptimeify.io/de/api/monitors/ftp-monitors/delete-ftp-monitor
Description: Löscht einen FTP Monitor.
Summary: `DELETE /api/ftp-monitors/:ftpMonitorPublicId` ## Authentifizierung `Authorization: Bearer <token>` ## Parameter - `ftpMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des FTP Monitors. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<your-api-token>" curl -X DELETE \ "$BASE_URL/api/ftp-monitors/55555555-5555-4555-8555-555555555555" \ -H "Authorization: Bearer $TOKEN" ``` ## Response ```json { "success": true } ``` ## Häufige Fehler - `401 Unauthorized` wenn du nicht authentifiziert bist - `403 Forbidden` wenn du keine Schreibrechte hast (z.B. Global Supporter oder Read-only) - `404 FTP monitor not found` wenn der Monitor nicht existiert

### FTP Monitor abrufen
URL: https://docs.uptimeify.io/de/api/monitors/ftp-monitors/get-ftp-monitor
Description: Gibt Details zu einem FTP Monitor zurück.
Summary: `GET /api/ftp-monitors/:ftpMonitorPublicId` Die Response enthält nur den FTP-Monitor selbst und bettet keinen vollständigen Kunden-Datensatz ein. ## Authentifizierung `Authorization: Bearer <token>` ## Parameter - `ftpMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des FTP Monitors. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<your-api-token>" curl -X GET \ "$BASE_URL/api/ftp-monitors/55555555-5555-4555-8555-555555555555" \ -H "Authorization: Bearer $TOKEN" ``` ## Response ```json { "id": 400, "organizationId": 1, "customerId": 10, "name": "Partner FTP", "hostname": "ftp.example.com", "port": 21, "status": "active", "checkInterval": 30, "timeoutSeconds": 30, "allowedCheckCountryCodes": null, "notificationPhoneNumber": null, "notificationEmail": null, "lastCheckedAt": null, "createdAt": "2026-02-25T10:00:00.000Z", "updatedAt": "2026-02-25T10:00:00.000Z", "config": { "user": "monitor", "password": "<ftp-password>", "secure": false }, "ftpConfig": { "user": "monitor", "password": "<ftp-password>", "secure": false } } ``` ## Häufige Fehler - `400 FTP monitor public ID (UUID) required` wenn `ftpMonitorPublicId` fehlt oder ungültig ist - `401 Unauthorized` wenn du nicht authentifiziert bist - `403 Forbidden` wenn du keinen Zugriff hast - `404 FTP monitor not found` wenn der Monitor nicht existiert

### FTP Monitor Alert-Historie abrufen
URL: https://docs.uptimeify.io/de/api/monitors/ftp-monitors/get-ftp-monitor-alert-history
Description: Gibt die Benachrichtigungs-/Eskalationsversuche (Alert-Historie) für Vorfälle eines FTP Monitors zurück.
Summary: `GET /api/ftp-monitors/:ftpMonitorPublicId/alert-history` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `ftpMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des FTP Monitors. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/ftp-monitors/11111111-1111-4111-8111-111111111111/alert-history" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Beispiel-Antwort ```json { "alerts": [ { "id": 987, "incidentId": 123, "type": "slack", "status": "sent", "channelName": "Ops Slack", "sentAt": "2026-02-26T12:11:00.000Z", "errorMessage": null } ], "total": 1 } ``` Jeder Eintrag ist ein Zustellversuch an einen Benachrichtigungskanal. `status` ist `sent` oder `failed` (bei Fehler ist `errorMessage` gesetzt); `type` ist der Kanaltyp (z. B. `email`, `slack`, `opsgenie`). ## Häufige Fehler - `400 FTP monitor public ID (UUID) required` wenn `:ftpMonitorPublicId` ungültig ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf den Monitor hast

### FTP Monitor Check-Historie abrufen
URL: https://docs.uptimeify.io/de/api/monitors/ftp-monitors/get-ftp-monitor-check-history
Description: Gibt die letzten FTP-Check-Ergebnisse für einen Monitor zurück.
Summary: `GET /api/ftp-monitors/:ftpMonitorPublicId/check-history` ## Authentifizierung `Authorization: Bearer <token>` ## Parameter - `ftpMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des FTP Monitors. - `limit` (Query, optional): Anzahl Ergebnisse (Default: 50, Max: 200) ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<your-api-token>" curl -X GET \ "$BASE_URL/api/ftp-monitors/55555555-5555-4555-8555-555555555555/check-history?limit=25" \ -H "Authorization: Bearer $TOKEN" ``` ## Beispiel Response ```json { "data": [ { "id": "2fd6d5ab-1e2a-4b4f-9c42-0f3a33a4a1d2", "status": "success", "errorMessage": null, "warningMessage": null, "timingFtp": 123, "diagnostics": { "message": "FTP connection successful" }, "checkedAt": "2026-02-25T10:05:00.000Z", "locationId": 7, "locationName": "Nuremberg (DE)", "locationCode": "de-nbg" } ] } ``` ## Häufige Fehler - `400 FTP monitor public ID (UUID) required` wenn `ftpMonitorPublicId` fehlt oder ungültig ist - `401 Unauthorized` wenn du nicht authentifiziert bist - `403 Forbidden` wenn du keinen Zugriff hast - `404 FTP monitor not found` wenn der Monitor nicht existiert

### FTP Monitor Details abrufen
URL: https://docs.uptimeify.io/de/api/monitors/ftp-monitors/get-ftp-monitor-details
Description: Gibt die FTP-Monitor-Detailseiten-Daten in einem Call zurück (Mega-Endpoint).
Summary: `GET /api/ftp-monitors/:ftpMonitorPublicId/details` ## Authentifizierung `Authorization: Bearer <token>` ## Parameter - `ftpMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des FTP Monitors. ## Query Parameter - `range` (optional): `day` (default), `week`, `month`, `year` - `date` (optional): Referenzdatum (ISO String) - `startDate` / `endDate` (optional): Überschreibt das Zeitfenster (ISO Strings) - `granularity` (optional): Wenn weggelassen, kann der Server bei großen Zeiträumen automatisch aggregieren. Nutze `granularity=raw`, um Raw-Daten zu erzwingen. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<your-api-token>" curl -X GET \ "$BASE_URL/api/ftp-monitors/55555555-5555-4555-8555-555555555555/details?range=day" \ -H "Authorization: Bearer $TOKEN" ``` ## Beispiel Response (Shape) Die Response ist ein einzelnes Objekt mit diesen Top-Level Keys: ```json { "ftpMonitorId": 400, "monitor": {}, "latestCheck": {}, "uptimeStats": { "day": "100.00", "month": "100.00", "year": "100.00", "dayAvgResponse": 120, "monthAvgResponse": 130, "yearAvgResponse": 140 }, "uptimeStatsMeta": {}, "monitoringData": { "responseTimeData": [], "statusData": [], "uptimePercentage": "100.00", "checkSuccessRatePercentage": "100.00", "totalChecks": 10, "successfulChecks": 10 }, "incidents": { "history": [], "total": 0, "ongoing": 0, "totalDowntime": "0s" }, "alerts": { "history": [], "total": 0, "notificationContext": {} }, "testResultLog": null, "maintenance": { "inMaintenance": false, "activeWindows": [], "allWindows": [] } } ``` ## Häufige Fehler - `400 Invalid FTP monitor public ID (UUID)` wenn `ftpMonitorPublicId` ungültig ist - `401 Unauthorized` wenn du nicht authentifiziert bist - `403 Forbidden` wenn du keinen Zugriff hast - `500 Failed to fetch FTP monitor details` bei Serverfehlern

### FTP Monitor Ausfall-Historie abrufen
URL: https://docs.uptimeify.io/de/api/monitors/ftp-monitors/get-ftp-monitor-incident-history
Description: Gibt die Vorfälle eines einzelnen FTP Monitors zurück (die letzten 100), inklusive berechneter Dauer.
Summary: `GET /api/ftp-monitors/:ftpMonitorPublicId/incident-history` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `ftpMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des FTP Monitors. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/ftp-monitors/11111111-1111-4111-8111-111111111111/incident-history" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Beispiel-Antwort ```json { "incidents": [ { "id": 123, "type": "downtime", "status": "resolved", "startedAt": "Feb 26, 2026, 12:10:00", "endedAt": "Feb 26, 2026, 12:12:30", "duration": "2m 30s" } ], "total": 1 } ``` `type` spiegelt die Fehlerkategorie dieses Monitors wider; `status` ist `active` (laufend) oder `resolved`. Laufende Vorfälle haben ein `null` bei `endedAt`. ## Häufige Fehler - `400 FTP monitor public ID (UUID) required` wenn `:ftpMonitorPublicId` ungültig ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf den Monitor hast

### FTP Monitore auflisten
URL: https://docs.uptimeify.io/de/api/monitors/ftp-monitors/list-ftp-monitors
Description: Listet FTP Monitore einer Organisation auf.
Summary: `GET /api/ftp-monitors` ## Authentifizierung `Authorization: Bearer <token>` ## Parameter - `organizationId` (Query, optional): Organisations-ID. Default ist die Organisation des aktuellen Nutzers. - `customerId` (Query, optional): Nach Kunden-ID filtern. - `search` (Query, optional): Suche nach Name, Hostname oder Kunde. - `page` (Query, optional): Seite (Default: 1). - `perPage` (Query, optional): Einträge pro Seite (Default: 50, Max: 200). Hinweis: Die Ergebnisse sind zusätzlich durch deinen Customer-Scope begrenzt (falls dein Account auf eine Teilmenge von Kunden eingeschränkt ist). ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<your-api-token>" curl -X GET \ "$BASE_URL/api/ftp-monitors?page=1&perPage=50&search=ftp" \ -H "Authorization: Bearer $TOKEN" ``` ## Response ```json { "items": [ { "id": 400, "organizationId": 1, "customerId": 10, "customerName": "Example Customer", "name": "Partner FTP", "hostname": "ftp.example.com", "port": 21, "status": "active", "checkInterval": 30, "timeoutSeconds": 30, "allowedCheckCountryCodes": null, "config": { "user": "monitor", "password": "<ftp-password>", "secure": false }, "notificationPhoneNumber": null, "notificationEmail": null, "lastCheckedAt": null, "createdAt": "2026-02-25T10:00:00.000Z", "updatedAt": "2026-02-25T10:00:00.000Z" } ], "total": 1, "page": 1, "perPage": 50 } ``` Jedes Item enthält den FTP-Monitor selbst und ein flaches `customerName`, aber keinen vollständig eingebetteten Kunden-Datensatz. ## Häufige Fehler - `400 Invalid organizationId` wenn `organizationId` keine gültige Zahl ist - `401 Unauthorized` wenn du nicht authentifiziert bist - `403 Forbidden` wenn du keinen Zugriff auf die Organisation hast

### FTP Check triggern
URL: https://docs.uptimeify.io/de/api/monitors/ftp-monitors/trigger-check-ftp-monitor
Description: Startet einen sofortigen Check von allen zulässigen Monitoring-Standorten.
Summary: `POST /api/ftp-monitors/:ftpMonitorPublicId/trigger-check` ## Authentifizierung `Authorization: Bearer <token>` ## Parameter - `ftpMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des FTP Monitors. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<your-api-token>" curl -X POST \ "$BASE_URL/api/ftp-monitors/55555555-5555-4555-8555-555555555555/trigger-check" \ -H "Authorization: Bearer $TOKEN" ``` ## Response ```json { "success": true, "message": "Checks triggered successfully", "ftpMonitorId": 400, "locationCodes": ["DE", "CH"], "queueNames": ["ftp-monitor-checks-DE", "ftp-monitor-checks-US"] } ``` ## Häufige Fehler - `400 FTP monitor public ID (UUID) required` wenn `ftpMonitorPublicId` fehlt oder ungültig ist - `400 No eligible monitoring locations for the selected allowed countries` wenn deine Country-Restriction keine aktiven Locations matched - `401 Unauthorized` wenn du nicht authentifiziert bist - `403 Forbidden` wenn du keine Schreibrechte hast - `503 No active monitoring locations available` wenn keine Worker-Locations aktiv sind

### FTP Monitor aktualisieren (Status ändern)
URL: https://docs.uptimeify.io/de/api/monitors/ftp-monitors/update-ftp-monitor
Description: Aktualisiert einen FTP Monitor und/oder ändert den Status.
Summary: `PATCH /api/ftp-monitors/:ftpMonitorPublicId` ## Authentifizierung `Authorization: Bearer <token>` ## Parameter - `ftpMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des FTP Monitors. ## Request Body - `status` (optional): `active`, `maintenance`, `disabled` (akzeptiert auch `inactive`/`paused` und normalisiert zu `disabled`) - `customerId` (optional, number): Muss zur selben Organisation gehören - `name` (optional, string) - `hostname` (optional, string): Muss ein Hostname sein (kein Protokoll, kein Pfad) - `port` (optional, number | null) - `checkInterval` (optional, number) - `timeoutSeconds` (optional, number) - `allowedCheckCountryCodes` (optional, string[] | null): ISO-3166-1 alpha-2, z.B. `"DE"`, `"CH"` - `ftpConfig` (optional, object): Ersetzt die gespeicherte FTP-Config (JSON) - `config` (optional, object): Alias von `ftpConfig` Hinweis: Read-only Nutzer dürfen nur `status` ändern. Hinweis: Wenn du `ftpConfig`/`config` weglässt, bleibt die bestehende Config unverändert. ```json { "status": "maintenance" } ``` ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<your-api-token>" curl -X PATCH \ "$BASE_URL/api/ftp-monitors/55555555-5555-4555-8555-555555555555" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"status":"active","allowedCheckCountryCodes":["DE","CH"],"ftpConfig":{"user":"monitor","password":"<ftp-password>","secure":false}}' ``` ## Response ```json { "id": 400, "status": "maintenance", "config": {}, "ftpConfig": {} } ``` ## Häufige Fehler - `400 Invalid status` wenn `status` ungültig ist - `401 Unauthorized` wenn du nicht authentifiziert bist - `403 Forbidden` wenn du keine Schreibrechte hast (z.B. Read-only versucht andere Felder zu ändern, oder Global Supporter) - `404 FTP monitor not found` wenn der Monitor nicht existiert

### ICMP Monitore
URL: https://docs.uptimeify.io/de/api/monitors/icmp-monitors
Description: Verwalte ICMP (Ping) Monitore.
Summary: Pfadbasierte ICMP-Monitor-Endpunkte verwenden `icmpMonitorPublicId`-UUIDs. ## Endpunkte - [ICMP Monitore auflisten](./icmp-monitore-auflisten) - [ICMP Monitor erstellen](./icmp-monitor-erstellen) - [ICMP Monitor abrufen](./icmp-monitor-abrufen) - [ICMP Monitor Details abrufen](./icmp-monitor-details-abrufen) - [ICMP Monitor Check-Historie abrufen](./icmp-monitor-check-historie-abrufen) - [ICMP Monitor aktualisieren](./icmp-monitor-aktualisieren-status) - [ICMP Monitor löschen](./icmp-monitor-loeschen) - [ICMP Check triggern](./icmp-monitor-check-triggern)

### ICMP Monitor erstellen
URL: https://docs.uptimeify.io/de/api/monitors/icmp-monitors/create-icmp-monitor
Description: Erstellt einen neuen ICMP Monitor.
Summary: `POST /api/icmp-monitors` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Request Body ```json { "customerId": "6764e84f-f02a-43e6-a46d-cecaec556723", "name": "Ping Gateway", "hostname": "claas.sh", "status": "active", "checkInterval": 5, "timeoutSeconds": 10, "icmpConfig": { "packetSize": 56, "count": 4 } } ``` ### Felder - `customerId` (number | string, required) - Akzeptiert die interne numerische Kunden-ID oder die Customer-`publicId`-UUID. - `name` (string, required) - `hostname` (string, required) - Muss nur Hostname oder IP sein (kein Protokoll wie `https://`, kein Pfad wie `/ping`). - `status` (string, optional) - Erlaubt: `active`, `maintenance`, `disabled`, `paused`, `inactive` - Hinweis: `paused` / `inactive` werden zu `disabled` normalisiert. - `checkInterval` (number, optional) - `timeoutSeconds` (number, optional) - `icmpConfig` (object, optional) - Wird als `config` JSON am Monitor gespeichert. ### `icmpConfig` (vom Worker unterstützte Keys) - `packetSize` (number) - Default: `56` - `count` (number) - Default: `3` ## cURL ```bash curl -X POST "https://YOUR_DOMAIN/api/icmp-monitors" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "customerId": "6764e84f-f02a-43e6-a46d-cecaec556723", "name": "Ping Gateway", "hostname": "claas.sh", "status": "active", "checkInterval": 5, "timeoutSeconds": 10, "icmpConfig": { "packetSize": 56, "count": 4 } }' ``` ## Response ```json { "id": 123, "organizationId": 1, "customerId": 2, "name": "Ping Gateway", "hostname": "claas.sh", "port": null, "status": "active", "checkInterval": 5, "timeoutSeconds": 10, "allowedCheckCountryCodes": null, "notificationPhoneNumber": null, "notificationEmail": null, "lastCheckedAt": null, "createdAt": "2026-02-26T12:00:00.000Z", "updatedAt": "2026-02-26T12:00:00.000Z", "config": { "packetSize": 56, "count": 4 }, "icmpConfig": { "packetSize": 56, "count": 4 } } ``` ## Fehler - `400 Invalid Customer identifier` - `400` Ungültiger Hostname oder ungültiger Request Body - `401` Unauthorized - `403` Forbidden (z. B. `readonly` oder global supporter) - `404` Kunde nicht gefunden

### ICMP Monitor löschen
URL: https://docs.uptimeify.io/de/api/monitors/icmp-monitors/delete-icmp-monitor
Description: Löscht einen ICMP Monitor.
Summary: `DELETE /api/icmp-monitors/:icmpMonitorPublicId` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `icmpMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des ICMP Monitors. ## cURL ```bash curl -X DELETE "https://YOUR_DOMAIN/api/icmp-monitors/22222222-2222-4222-8222-222222222222" \ -H "Authorization: Bearer $TOKEN" ``` ## Response ```json { "success": true } ``` ## Fehler - `400` ICMP Monitor Public ID (UUID) erforderlich - `401` Unauthorized - `403` Forbidden - `404` ICMP Monitor nicht gefunden

### ICMP Monitor abrufen
URL: https://docs.uptimeify.io/de/api/monitors/icmp-monitors/get-icmp-monitor
Description: Gibt Details zu einem ICMP Monitor zurück.
Summary: `GET /api/icmp-monitors/:icmpMonitorPublicId` Die Response enthält nur den ICMP-Monitor selbst und bettet keinen vollständigen Kunden-Datensatz ein. ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `icmpMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des ICMP-Monitors. ## cURL ```bash curl "https://YOUR_DOMAIN/api/icmp-monitors/22222222-2222-4222-8222-222222222222" \ -H "Authorization: Bearer $TOKEN" ``` ## Response ```json { "id": 123, "organizationId": 1, "customerId": 10, "name": "Core Router", "hostname": "10.0.0.1", "port": null, "status": "active", "checkInterval": 30, "timeoutSeconds": 30, "config": { "packetSize": 56, "count": 3 }, "notificationPhoneNumber": null, "notificationEmail": null, "lastCheckedAt": null, "createdAt": "2026-02-26T12:00:00.000Z", "updatedAt": "2026-02-26T12:00:00.000Z", "icmpConfig": { "packetSize": 56, "count": 3 } } ``` ## Fehler - `400` ICMP Monitor Public ID (UUID) erforderlich - `401` Unauthorized - `403` Forbidden - `404` ICMP Monitor nicht gefunden

### ICMP Monitor Alert-Historie abrufen
URL: https://docs.uptimeify.io/de/api/monitors/icmp-monitors/get-icmp-monitor-alert-history
Description: Gibt die Benachrichtigungs-/Eskalationsversuche (Alert-Historie) für Vorfälle eines ICMP Monitors zurück.
Summary: `GET /api/icmp-monitors/:icmpMonitorPublicId/alert-history` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `icmpMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des ICMP Monitors. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/icmp-monitors/11111111-1111-4111-8111-111111111111/alert-history" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Beispiel-Antwort ```json { "alerts": [ { "id": 987, "incidentId": 123, "type": "slack", "status": "sent", "channelName": "Ops Slack", "sentAt": "2026-02-26T12:11:00.000Z", "errorMessage": null } ], "total": 1 } ``` Jeder Eintrag ist ein Zustellversuch an einen Benachrichtigungskanal. `status` ist `sent` oder `failed` (bei Fehler ist `errorMessage` gesetzt); `type` ist der Kanaltyp (z. B. `email`, `slack`, `opsgenie`). ## Häufige Fehler - `400 ICMP monitor public ID (UUID) required` wenn `:icmpMonitorPublicId` ungültig ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf den Monitor hast

### ICMP Monitor Check-Historie abrufen
URL: https://docs.uptimeify.io/de/api/monitors/icmp-monitors/get-icmp-monitor-check-history
Description: Gibt die letzten Check-Ergebnisse für den ICMP Monitor zurück.
Summary: `GET /api/icmp-monitors/:icmpMonitorPublicId/check-history` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `icmpMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des ICMP Monitors. - `limit` (Query, optional): Maximale Anzahl an Ergebnissen (Default: 50, Max: 200). ## cURL ```bash curl -X GET "https://YOUR_DOMAIN/api/icmp-monitors/22222222-2222-4222-8222-222222222222/check-history?limit=50" \ -H "Authorization: Bearer $TOKEN" ``` ## Response ```json { "data": [ { "id": "f6b0e5a7-4c4a-4d3b-9f6b-0e5a74c4a4d3", "status": "success", "errorMessage": null, "warningMessage": null, "timingIcmp": 22, "diagnostics": { "min": 11.1, "avg": 22.2, "max": 33.3, "packetLoss": 0 }, "checkedAt": "2026-02-26T12:00:00.000Z", "locationId": 7, "locationName": "Nuremberg (DE)", "locationCode": "de-nbg" } ] } ``` ## Fehler - `400` ICMP Monitor Public ID (UUID) erforderlich - `401` Unauthorized - `403` Forbidden - `404` ICMP Monitor nicht gefunden

### ICMP Monitor Details abrufen
URL: https://docs.uptimeify.io/de/api/monitors/icmp-monitors/get-icmp-monitor-details
Description: Gibt ein konsolidiertes Payload zurück, das in der Monitor-Detailseite verwendet wird (u. a. Monitor, letzter Check, aggregierte Daten im Zeitbereich).
Summary: `GET /api/icmp-monitors/:icmpMonitorPublicId/details` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `icmpMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des ICMP Monitors. ### Time-Range Query-Parameter Der Zeitbereich kann auf mehrere Arten definiert werden. Nutze die einfachste Option für deinen Use-Case: - `range` (Query, optional): Preset-Zeitraum. - Erlaubt: `day` (Default), `week`, `month`, `year` - `date` (Query, optional): Referenzdatum, das als Default-Ende verwendet wird. - Beispiel: `2026-02-26` - `startDate` (Query, optional): Startdatum/-zeit. - `endDate` (Query, optional): Enddatum/-zeit. - `granularity` (Query, optional): Steuert Aggregation. - Nutze `raw`, um Aggregation zu deaktivieren. - Jeder andere Wert aktiviert Aggregation. - Wenn nicht gesetzt, aggregiert der Server ggf. automatisch bei größeren Zeitbereichen. ## cURL ```bash curl -X GET "https://YOUR_DOMAIN/api/icmp-monitors/22222222-2222-4222-8222-222222222222/details?range=day&granularity=raw" \ -H "Authorization: Bearer $TOKEN" ``` ## Response Top-Level Felder (aktueller Stand): - `icmpMonitorId` - `monitor` - `latestCheck` - `uptimeStats`, `uptimeStatsMeta` - `monitoringData` - `incidents` - `alerts` - `testResultLog` - `maintenance` Beispiel: ```json { "icmpMonitorId": 123, "monitor": { "id": 123, "customerId": 10, "organizationId": 1, "name": "Core Router", "hostname": "10.0.0.1", "status": "active", "checkInterval": 30, "timeoutSeconds": 30, "port": null, "config": { "packetSize": 56, "count": 3 }, "notificationPhoneNumber": null, "notificationEmail": null, "lastCheckedAt": null, "createdAt": "2026-02-26T12:00:00.000Z", "updatedAt": "2026-02-26T12:00:00.000Z" }, "latestCheck": null, "uptimeStats": { "day": "100.00", "month": "100.00", "year": "100.00", "dayAvgResponse": 22, "monthAvgResponse": 22, "yearAvgResponse": 22 }, "uptimeStatsMeta": { "day": { "window": "24h", "downtimeMinutes": 0, "incidents": 0, "checksTotal": 24, "checksFailed": 0 }, "month": { "window": "30d", "downtimeMinutes": 0, "incidents": 0, "checksTotal": 720, "checksFailed": 0 }, "year": { "window": "YTD", "downtimeMinutes": 0, "incidents": 0, "checksTotal": 1000, "checksFailed": 0 } }, "monitoringData": { "responseTimeData": [ { "timestamp": "2026-02-26T12:00:00.000Z", "responseTime": 22, "status": "success", "success": true, "timingDns": 0, "timingTcp": 22, "timingTls": 0, "timingTtfb": 0, "timingTransfer": 0 } ], "statusData": [{ "date": "26.02", "status": "online" }], "uptimePercentage": "100.00", "checkSuccessRatePercentage": "100.00", "totalChecks": 100, "successfulChecks": 100 }, "incidents": { "history": [], "total": 0, "ongoing": 0, "totalDowntime": "0s" }, "alerts": { "history": [], "total": 0, "notificationContext": { "orgDefaultEmail": null, "orgDefaultPhoneNumber": null, "customerEmail": null, "notificationTargets": [] } }, "testResultLog": [], "maintenance": { "inMaintenance": false, "activeWindows": [], "allWindows": [] } } ``` ## Fehler - `400` Ungültige ICMP Monitor Public ID (UUID) - `401` Unauthorized - `403` Forbidden - `404` ICMP Monitor nicht gefunden - `500` Failed to fetch ICMP monitor details

### ICMP Monitor Ausfall-Historie abrufen
URL: https://docs.uptimeify.io/de/api/monitors/icmp-monitors/get-icmp-monitor-incident-history
Description: Gibt die Vorfälle eines einzelnen ICMP Monitors zurück (die letzten 100), inklusive berechneter Dauer.
Summary: `GET /api/icmp-monitors/:icmpMonitorPublicId/incident-history` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `icmpMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des ICMP Monitors. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/icmp-monitors/11111111-1111-4111-8111-111111111111/incident-history" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Beispiel-Antwort ```json { "incidents": [ { "id": 123, "type": "downtime", "status": "resolved", "startedAt": "Feb 26, 2026, 12:10:00", "endedAt": "Feb 26, 2026, 12:12:30", "duration": "2m 30s" } ], "total": 1 } ``` `type` spiegelt die Fehlerkategorie dieses Monitors wider; `status` ist `active` (laufend) oder `resolved`. Laufende Vorfälle haben ein `null` bei `endedAt`. ## Häufige Fehler - `400 ICMP monitor public ID (UUID) required` wenn `:icmpMonitorPublicId` ungültig ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf den Monitor hast

### ICMP Monitore auflisten
URL: https://docs.uptimeify.io/de/api/monitors/icmp-monitors/list-icmp-monitors
Description: Listet ICMP Monitore einer Organisation auf.
Summary: `GET /api/icmp-monitors` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `organizationId` (Query, optional): Organisations-ID. Default ist die Organisation des aktuellen Nutzers. - `customerId` (Query, optional): Nach Kunden-ID filtern. - `search` (Query, optional): Suche nach Name, Hostname oder Kunde. - `page` (Query, optional): Seite (Default: 1). - `perPage` (Query, optional): Einträge pro Seite (Default: 50, Max: 200). ## cURL ```bash curl "https://YOUR_DOMAIN/api/icmp-monitors?page=1&perPage=50" \ -H "Authorization: Bearer $TOKEN" ``` ## Response ```json { "items": [ { "id": 123, "organizationId": 1, "customerId": 10, "customerName": "Example Customer", "name": "Core Router", "hostname": "10.0.0.1", "status": "active", "checkInterval": 30, "timeoutSeconds": 30, "port": null, "config": { "packetSize": 56, "count": 3 }, "notificationPhoneNumber": null, "notificationEmail": null, "lastCheckedAt": null, "createdAt": "2026-02-26T12:00:00.000Z", "updatedAt": "2026-02-26T12:00:00.000Z" } ], "total": 1, "page": 1, "perPage": 50 } ``` Jedes Item enthält den ICMP-Monitor selbst und ein flaches `customerName`, aber keinen vollständig eingebetteten Kunden-Datensatz. ## Fehler - `400` Ungültige Query-Parameter (z. B. `organizationId`, `customerId`) - `401` Unauthorized - `403` Forbidden

### ICMP Check triggern
URL: https://docs.uptimeify.io/de/api/monitors/icmp-monitors/trigger-check-icmp-monitor
Description: Startet einen sofortigen Check von allen zulässigen Monitoring-Standorten.
Summary: `POST /api/icmp-monitors/:icmpMonitorPublicId/trigger-check` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `icmpMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des ICMP Monitors. ## cURL ```bash curl -X POST "https://YOUR_DOMAIN/api/icmp-monitors/22222222-2222-4222-8222-222222222222/trigger-check" \ -H "Authorization: Bearer $TOKEN" ``` ## Response ```json { "success": true, "message": "Checks triggered successfully", "icmpMonitorId": 123, "locationCodes": ["de-nbg", "fi-hel"], "queueNames": ["icmp-monitor-checks-de-nbg", "icmp-monitor-checks-fi-hel"] } ``` ## Fehler - `400` ICMP Monitor Public ID (UUID) erforderlich oder keine zulässigen Standorte - `401` Unauthorized - `403` Forbidden - `404` ICMP Monitor nicht gefunden - `503` Keine aktiven Monitoring-Standorte verfügbar - `500` Failed to trigger check

### ICMP Monitor aktualisieren
URL: https://docs.uptimeify.io/de/api/monitors/icmp-monitors/update-icmp-monitor
Description: Aktualisiert einen ICMP Monitor. Dieser Endpunkt wird auch genutzt, um den Status zu wechseln.
Summary: `PATCH /api/icmp-monitors/:icmpMonitorPublicId` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `icmpMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des ICMP Monitors. ## Request Body Alle Felder sind optional. - `status` (optional) - Erlaubt: `active`, `maintenance`, `disabled`, `paused`, `inactive` - Hinweis: `paused` / `inactive` werden zu `disabled` normalisiert. - `name`, `hostname`, `checkInterval`, `timeoutSeconds` (optional) - `port` (optional) - Wird von der API akzeptiert, aktuell aber nicht vom ICMP Worker genutzt. - `allowedCheckCountryCodes` (optional) - Wird auf Großbuchstaben normalisiert und dedupliziert. - `icmpConfig` (optional) - Alias für das gespeicherte `config` JSON. - `config` (optional) - Alternative Möglichkeit, das gleiche gespeicherte `config` JSON zu aktualisieren. Hinweis: Read-only Nutzer dürfen nur `status` ändern (und das Senden anderer Felder führt zu `403`). ```json { "status": "maintenance", "allowedCheckCountryCodes": ["DE", "CH"] } ``` Beispiel Konfiguration aktualisieren: ```json { "icmpConfig": { "packetSize": 56, "count": 3 } } ``` ## cURL ```bash curl -X PATCH "https://YOUR_DOMAIN/api/icmp-monitors/22222222-2222-4222-8222-222222222222" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "status": "disabled" }' ``` ## Response ```json { "id": 123, "status": "maintenance", "organizationId": 1, "customerId": 10, "name": "Core Router", "hostname": "10.0.0.1", "port": null, "checkInterval": 30, "timeoutSeconds": 30, "allowedCheckCountryCodes": ["DE", "CH"], "notificationPhoneNumber": null, "notificationEmail": null, "lastCheckedAt": null, "createdAt": "2026-02-26T12:00:00.000Z", "updatedAt": "2026-02-26T12:05:00.000Z", "config": { "packetSize": 56, "count": 3 }, "icmpConfig": { "packetSize": 56, "count": 3 } } ``` ## Fehler - `400` Ungültiger Request Body, ungültiger Status oder ungültiger Hostname - `401` Unauthorized - `403` Forbidden (z. B. `readonly` oder global supporter) - `404` ICMP Monitor nicht gefunden

### IMAP/POP Monitore
URL: https://docs.uptimeify.io/de/api/monitors/imap-pop-monitors
Description: Verwalte IMAP/POP Monitore.
Summary: Pfadbasierte IMAP/POP-Monitor-Endpunkte verwenden `imapPopMonitorPublicId`-UUIDs. ## Endpunkte - [IMAP/POP Monitore auflisten](./imap-pop-monitore-auflisten) - [IMAP/POP Monitor erstellen](./imap-pop-monitor-erstellen) - [IMAP/POP Monitor abrufen](./imap-pop-monitor-abrufen) - [IMAP/POP Monitor aktualisieren](./imap-pop-monitor-aktualisieren-status) - [IMAP/POP Monitor löschen](./imap-pop-monitor-loeschen) - [IMAP/POP Check triggern](./imap-pop-monitor-check-triggern) - [IMAP/POP Monitor Details abrufen](./imap-pop-monitor-details-abrufen) - [IMAP/POP Monitor Check Historie abrufen](./imap-pop-monitor-check-historie-abrufen)

### IMAP/POP Monitor erstellen
URL: https://docs.uptimeify.io/de/api/monitors/imap-pop-monitors/create-imap-pop-monitor
Description: Erstellt einen neuen IMAP/POP Monitor.
Summary: `POST /api/imap-pop-monitors` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Request Body ```json { "customerId": "11111111-1111-4111-8111-111111111111", "name": "Mailbox Access", "hostname": "mail.example.com", "port": 993, "status": "active", "checkInterval": 30, "timeoutSeconds": 30, "imapPopConfig": { "protocol": "imap", "user": "monitor@example.com", "password": "password", "tls": true, "tlsOptions": { "rejectUnauthorized": true } } } ``` ### Felder - `customerId` (number | string, required) - Akzeptiert entweder die interne numerische Kunden-ID oder die öffentliche Kunden-UUID. - `name` (string, required) - `hostname` (string, required) - Muss ein Hostname sein (kein Protokoll wie `https://`, kein Pfad wie `/imap`). - `port` (number | null, optional) - Wenn weggelassen oder `null`, wählt der Worker einen Default-Port abhängig von `imapPopConfig.protocol` und `imapPopConfig.tls`. - `status` (string, optional) - Erlaubt: `active`, `maintenance`, `disabled`, `paused`, `inactive` - Hinweis: `paused` / `inactive` werden zu `disabled` normalisiert. - `checkInterval` (number, optional) - `timeoutSeconds` (number, optional) - `imapPopConfig` (object, optional) - Wird als `config` JSON gespeichert. ### `imapPopConfig` (vom Worker unterstützte Keys) - `protocol` (`imap` | `pop3`) - Default: `imap` - `user` (string) - `password` (string) - `tls` (boolean) - Default: `false` - `tlsOptions.rejectUnauthorized` (boolean) - Wird von der IMAP Worker-Library genutzt; POP3 ignoriert diese Option aktuell. ### Default-Ports (Worker-Verhalten) Wenn `port` weggelassen oder `null` ist: - IMAP: - TLS (`tls: true`): `993` - Non-TLS (`tls: false`): `143` - POP3: - TLS (`tls: true`): `995` - Non-TLS (`tls: false`): `110` ## cURL ```bash curl -X POST "https://YOUR_DOMAIN/api/imap-pop-monitors" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "customerId": "11111111-1111-4111-8111-111111111111", "name": "Mailbox Access", "hostname": "mail.example.com", "port": 993, "status": "active", "checkInterval": 30, "timeoutSeconds": 30, "imapPopConfig": { "protocol": "imap", "user": "monitor@example.com", "password": "password", "tls": true } }' ``` ## Response ```json { "id": 500, "organizationId": 1, "customerId": 10, "name": "Mailbox Access", "hostname": "mail.example.com", "port": 993, "checkInterval": 30, "timeoutSeconds": 30, "status": "active", "notificationPhoneNumber": null, "notificationEmail": null, "lastCheckedAt": null, "createdAt": "2026-02-26T12:00:00.000Z", "updatedAt": "2026-02-26T12:00:00.000Z", "config": { "protocol": "imap", "user": "monitor@example.com", "password": "password", "tls": true }, "imapPopConfig": { "protocol": "imap", "user": "monitor@example.com", "password": "password", "tls": true } } ``` ## Errors - `400` Ungültiger Hostname oder ungültiger Request Body - `400` Ungültiger Customer-Identifier - `401` Unauthorized - `403` Forbidden (z.B. `readonly` oder global supporter) - `404` Customer not found

### IMAP/POP Monitor löschen
URL: https://docs.uptimeify.io/de/api/monitors/imap-pop-monitors/delete-imap-pop-monitor
Description: Löscht einen IMAP/POP Monitor.
Summary: `DELETE /api/imap-pop-monitors/:imapPopMonitorPublicId` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `imapPopMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des IMAP/POP Monitors. ## Response ```json { "success": true } ``` ## Errors - `400` IMAP/POP Monitor Public ID (UUID) erforderlich - `401` Unauthorized - `403` Forbidden (z.B. `readonly` oder global supporter) - `404` IMAP/POP monitor not found

### IMAP/POP Monitor abrufen
URL: https://docs.uptimeify.io/de/api/monitors/imap-pop-monitors/get-imap-pop-monitor
Description: Gibt Details zu einem IMAP/POP Monitor zurück.
Summary: `GET /api/imap-pop-monitors/:imapPopMonitorPublicId` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `imapPopMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des IMAP/POP Monitors. ## cURL ```bash curl -X GET "https://YOUR_DOMAIN/api/imap-pop-monitors/66666666-6666-4666-8666-666666666666" \ -H "Authorization: Bearer $TOKEN" ``` ## Response ```json { "id": 500, "organizationId": 1, "customerId": 10, "name": "Mailbox Access", "hostname": "mail.example.com", "port": 993, "checkInterval": 30, "timeoutSeconds": 30, "config": { "protocol": "imap", "user": "monitor@example.com", "password": "password", "tls": true }, "allowedCheckCountryCodes": null, "status": "active", "notificationPhoneNumber": null, "notificationEmail": null, "lastCheckedAt": null, "createdAt": "2026-02-26T12:00:00.000Z", "updatedAt": "2026-02-26T12:00:00.000Z", "customer": { "id": 10, "organizationId": 1, "name": "Example Customer", "email": "ops@example.com", "allowedCheckCountryCodes": null, "customFields": null, "alertLocationThresholdCount": 1, "createdAt": "2026-02-01T12:00:00.000Z", "updatedAt": "2026-02-01T12:00:00.000Z" }, "imapPopConfig": { "protocol": "imap", "user": "monitor@example.com", "password": "password", "tls": true } } ``` ## Errors - `400` IMAP/POP Monitor Public ID (UUID) erforderlich - `401` Unauthorized - `403` Forbidden - `404` IMAP/POP monitor not found

### IMAP/POP Monitor Alert-Historie abrufen
URL: https://docs.uptimeify.io/de/api/monitors/imap-pop-monitors/get-imap-pop-monitor-alert-history
Description: Gibt die Benachrichtigungs-/Eskalationsversuche (Alert-Historie) für Vorfälle eines IMAP/POP Monitors zurück.
Summary: `GET /api/imap-pop-monitors/:imapPopMonitorPublicId/alert-history` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `imapPopMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des IMAP/POP Monitors. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/imap-pop-monitors/11111111-1111-4111-8111-111111111111/alert-history" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Beispiel-Antwort ```json { "alerts": [ { "id": 987, "incidentId": 123, "type": "slack", "status": "sent", "channelName": "Ops Slack", "sentAt": "2026-02-26T12:11:00.000Z", "errorMessage": null } ], "total": 1 } ``` Jeder Eintrag ist ein Zustellversuch an einen Benachrichtigungskanal. `status` ist `sent` oder `failed` (bei Fehler ist `errorMessage` gesetzt); `type` ist der Kanaltyp (z. B. `email`, `slack`, `opsgenie`). ## Häufige Fehler - `400 IMAP/POP monitor public ID (UUID) required` wenn `:imapPopMonitorPublicId` ungültig ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf den Monitor hast

### IMAP/POP Monitor Check Historie abrufen
URL: https://docs.uptimeify.io/de/api/monitors/imap-pop-monitors/get-imap-pop-monitor-check-history
Description: Gibt die letzten Check-Ergebnisse für den IMAP/POP Monitor zurück.
Summary: `GET /api/imap-pop-monitors/:imapPopMonitorPublicId/check-history` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `imapPopMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des IMAP/POP Monitors. - `limit` (Query, optional): Maximale Anzahl Ergebnisse (Default: 50, Max: 200). ## cURL ```bash curl -X GET "https://YOUR_DOMAIN/api/imap-pop-monitors/66666666-6666-4666-8666-666666666666/check-history?limit=50" \ -H "Authorization: Bearer $TOKEN" ``` ## Response ```json { "data": [ { "id": 123, "status": "success", "errorMessage": null, "warningMessage": null, "timingImapPop": 142, "diagnostics": { "message": "IMAP connection successful" }, "checkedAt": "2026-02-26T12:00:00.000Z", "locationId": 7, "locationName": "Nuremberg (DE)", "locationCode": "de-nbg" } ] } ``` ## Errors - `400` IMAP/POP Monitor Public ID (UUID) erforderlich - `401` Unauthorized - `403` Forbidden - `404` IMAP/POP monitor not found

### IMAP/POP Monitor Details abrufen
URL: https://docs.uptimeify.io/de/api/monitors/imap-pop-monitors/get-imap-pop-monitor-details
Description: Konsolidierter Endpunkt, der das IMAP/POP Monitor Detailseiten-Payload in einem Call zurückgibt (latest check, uptime stats, incidents, alert history, maintenance windows, chart data, etc.).
Summary: `GET /api/imap-pop-monitors/:imapPopMonitorPublicId/details` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `imapPopMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des IMAP/POP Monitors. - `range` (Query, optional): `day` | `week` | `month` | `year` (Default: `day`). - `date` (Query, optional): Referenzdatum als ISO String. - `startDate` (Query, optional): Override Startdatum als ISO String. - `endDate` (Query, optional): Override Enddatum als ISO String. - `granularity` (Query, optional): Wenn gesetzt und nicht `raw`, kann das Backend Chart-Daten aggregieren. ## cURL ```bash curl -X GET "https://YOUR_DOMAIN/api/imap-pop-monitors/66666666-6666-4666-8666-666666666666/details?range=day" \ -H "Authorization: Bearer $TOKEN" ``` ## Response Die Response ist ein großes Objekt. Wichtige Top-Level Felder: - `imapPopMonitorId` - `monitor` - `latestCheck` - `uptimeStats`, `uptimeStatsMeta` - `monitoringData` - `incidents` - `alerts` - `testResultLog` - `maintenance` Beispiel (gekürzt): ```json { "imapPopMonitorId": 500, "monitor": { "id": 500, "hostname": "mail.example.com", "status": "active" }, "latestCheck": { "id": 123, "status": "success", "checkedAt": "2026-02-26T12:00:00.000Z" }, "uptimeStats": { "day": "100.00", "month": "100.00", "year": "100.00", "dayAvgResponse": 142, "monthAvgResponse": 150, "yearAvgResponse": 160 }, "maintenance": { "inMaintenance": false, "activeWindows": [], "allWindows": [] } } ``` ## Errors - `400` Ungültige IMAP/POP Monitor Public ID (UUID) - `401` Unauthorized - `403` Forbidden - `404` IMAP/POP monitor not found - `500` Failed to fetch IMAP/POP monitor details

### IMAP/POP Monitor Ausfall-Historie abrufen
URL: https://docs.uptimeify.io/de/api/monitors/imap-pop-monitors/get-imap-pop-monitor-incident-history
Description: Gibt die Vorfälle eines einzelnen IMAP/POP Monitors zurück (die letzten 100), inklusive berechneter Dauer.
Summary: `GET /api/imap-pop-monitors/:imapPopMonitorPublicId/incident-history` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `imapPopMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des IMAP/POP Monitors. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/imap-pop-monitors/11111111-1111-4111-8111-111111111111/incident-history" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Beispiel-Antwort ```json { "incidents": [ { "id": 123, "type": "downtime", "status": "resolved", "startedAt": "Feb 26, 2026, 12:10:00", "endedAt": "Feb 26, 2026, 12:12:30", "duration": "2m 30s" } ], "total": 1 } ``` `type` spiegelt die Fehlerkategorie dieses Monitors wider; `status` ist `active` (laufend) oder `resolved`. Laufende Vorfälle haben ein `null` bei `endedAt`. ## Häufige Fehler - `400 IMAP/POP monitor public ID (UUID) required` wenn `:imapPopMonitorPublicId` ungültig ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf den Monitor hast

### IMAP/POP Monitore auflisten
URL: https://docs.uptimeify.io/de/api/monitors/imap-pop-monitors/list-imap-pop-monitors
Description: Listet IMAP/POP Monitore einer Organisation auf.
Summary: `GET /api/imap-pop-monitors` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `organizationId` (Query, optional): Organisations-ID. Default ist die Organisation des aktuellen Nutzers. - `customerId` (Query, optional): Nach Kunden-ID filtern. - `search` (Query, optional): Suche nach Name, Hostname oder Kunde. - `page` (Query, optional): Seite (Default: 1). - `perPage` (Query, optional): Einträge pro Seite (Default: 50, Max: 200). ## cURL ```bash curl "https://YOUR_DOMAIN/api/imap-pop-monitors?page=1&perPage=50" \ -H "Authorization: Bearer $TOKEN" ``` ## Response ```json { "items": [ { "id": 500, "organizationId": 1, "customerId": 10, "name": "Mailbox Access", "hostname": "mail.example.com", "port": 993, "checkInterval": 30, "timeoutSeconds": 30, "customerName": "Example Customer", "config": { "protocol": "imap", "user": "monitor@example.com", "password": "password", "tls": true }, "status": "active", "notificationPhoneNumber": null, "notificationEmail": null, "lastCheckedAt": null, "createdAt": "2026-02-26T12:00:00.000Z", "updatedAt": "2026-02-26T12:00:00.000Z" } ], "total": 1, "page": 1, "perPage": 50 } ``` ## Errors - `400` Ungültige Query Parameter (z.B. `organizationId`, `customerId`) - `401` Unauthorized - `403` Forbidden

### IMAP/POP Check triggern
URL: https://docs.uptimeify.io/de/api/monitors/imap-pop-monitors/trigger-check-imap-pop-monitor
Description: Startet einen sofortigen Check von allen zulässigen Monitoring-Standorten.
Summary: `POST /api/imap-pop-monitors/:imapPopMonitorPublicId/trigger-check` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `imapPopMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des IMAP/POP Monitors. ## Response ```json { "success": true, "message": "Checks triggered successfully", "imapPopMonitorId": 500, "locationCodes": ["de-nbg", "fi-hel"], "queueNames": ["imap-pop-monitor-checks-de-nbg", "imap-pop-monitor-checks-fi-hel"] } ``` ## Errors - `400` Ungültige IMAP/POP Monitor Public ID (UUID) oder keine zulässigen Locations - `401` Unauthorized - `403` Forbidden - `404` IMAP/POP monitor not found - `503` No active monitoring locations available - `500` Failed to trigger check

### IMAP/POP Monitor aktualisieren
URL: https://docs.uptimeify.io/de/api/monitors/imap-pop-monitors/update-imap-pop-monitor
Description: Aktualisiert einen IMAP/POP Monitor und/oder ändert den Status.
Summary: `PATCH /api/imap-pop-monitors/:imapPopMonitorPublicId` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `imapPopMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des IMAP/POP Monitors. ## Request Body - `status` (optional) - Erlaubt: `active`, `maintenance`, `disabled`, `paused`, `inactive` - Hinweis: `paused` / `inactive` werden zu `disabled` normalisiert. - `name`, `hostname`, `port`, `checkInterval`, `timeoutSeconds` (optional) - `allowedCheckCountryCodes` (optional) - Wird zu Uppercase normalisiert und dedupliziert. - `imapPopConfig` (optional) - Alias für das gespeicherte `config` JSON. - `config` (optional) - Alternative, um dasselbe gespeicherte `config` JSON zu aktualisieren. Hinweis: Read-only Nutzer dürfen nur `status` ändern (bei anderen Feldern kommt `403`). ```json { "status": "active" } ``` Beispiel für Config-Update: ```json { "imapPopConfig": { "protocol": "pop3", "tls": true, "user": "monitor@example.com", "password": "password" } } ``` ## Response ```json { "id": 500, "organizationId": 1, "customerId": 10, "name": "Mailbox Access", "hostname": "mail.example.com", "port": 993, "checkInterval": 30, "timeoutSeconds": 30, "status": "active", "notificationPhoneNumber": null, "notificationEmail": null, "lastCheckedAt": null, "createdAt": "2026-02-26T12:00:00.000Z", "updatedAt": "2026-02-26T12:05:00.000Z", "config": { "protocol": "pop3", "tls": true, "user": "monitor@example.com", "password": "password" }, "imapPopConfig": { "protocol": "pop3", "tls": true, "user": "monitor@example.com", "password": "password" } } ``` ## Errors - `400` Ungültiger Request Body, ungültiger Status oder ungültiger Hostname - `401` Unauthorized - `403` Forbidden (z.B. `readonly` oder global supporter) - `404` IMAP/POP monitor not found

### SMTP Monitore
URL: https://docs.uptimeify.io/de/api/monitors/smtp-monitors
Description: Verwalte SMTP Monitore.
Summary: Pfadbasierte SMTP-Monitor-Endpunkte verwenden `smtpMonitorPublicId`-UUIDs. ## Endpunkte - [SMTP Monitore auflisten](./smtp-monitore-auflisten) - [SMTP Monitor erstellen](./smtp-monitor-erstellen) - [SMTP Monitor abrufen](./smtp-monitor-abrufen) - [SMTP Monitor Details abrufen](./smtp-monitor-details-abrufen) - [SMTP Monitor Check-Historie abrufen](./smtp-monitor-check-historie-abrufen) - [SMTP Monitor aktualisieren](./smtp-monitor-aktualisieren-status) - [SMTP Monitor löschen](./smtp-monitor-loeschen) - [Check für SMTP Monitor triggern](./smtp-monitor-check-triggern)

### SMTP Monitor erstellen
URL: https://docs.uptimeify.io/de/api/monitors/smtp-monitors/create-smtp-monitor
Description: Erstellt einen neuen SMTP Monitor.
Summary: `POST /api/smtp-monitors` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Request Body ```json { "customerId": "11111111-1111-4111-8111-111111111111", "name": "Outbound SMTP", "hostname": "smtp.example.com", "port": 587, "status": "active", "checkInterval": 60, "timeoutSeconds": 30, "smtpConfig": { "secure": false, "ignoreTls": false, "requireTls": false, "auth": { "user": "username", "pass": "password" } } } ``` ### Felder - `customerId` (number | string, erforderlich) - Akzeptiert entweder die interne numerische Kunden-ID oder die öffentliche Kunden-UUID. - `name` (string, erforderlich) - `hostname` (string, erforderlich) - Muss nur ein Hostname sein (kein Protokoll wie `https://`, kein Pfad wie `/smtp`). - `port` (number | null, optional) - Wenn weggelassen oder `null`, nutzt der Worker standardmäßig `465`, wenn `smtpConfig.secure=true`, sonst `25`. - `status` (string, optional) - Erlaubt: `active`, `maintenance`, `disabled`, `paused`, `inactive` - `checkInterval` (number, optional) - `timeoutSeconds` (number, optional) - `smtpConfig` (object, optional) - Wird als `config` JSON des Monitors gespeichert. ### `smtpConfig` (vom Worker unterstützte Keys) Der SMTP Worker nutzt/normalisiert diese Keys: - `secure` (boolean, default `false`) - `ignoreTls` (boolean, default `false`) - `requireTls` (boolean, default `false`) - `auth.user` und `auth.pass` (strings) - Credentials werden nur verwendet, wenn *beide* `user` und `pass` gesetzt sind. ## cURL ```bash curl -X POST "https://YOUR_DOMAIN/api/smtp-monitors" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "customerId": "11111111-1111-4111-8111-111111111111", "name": "Outbound SMTP", "hostname": "smtp.example.com", "port": 587, "status": "active", "checkInterval": 60, "timeoutSeconds": 30, "smtpConfig": { "secure": false, "ignoreTls": false, "requireTls": false, "auth": { "user": "username", "pass": "password" } } }' ``` ## Response ```json { "id": 200, "organizationId": 1, "customerId": 10, "name": "Outbound SMTP", "hostname": "smtp.example.com", "port": 587, "status": "active", "checkInterval": 60, "timeoutSeconds": 30, "notificationEmail": null, "notificationPhoneNumber": null, "lastCheckedAt": null, "createdAt": "2026-01-01T12:00:00.000Z", "updatedAt": "2026-01-01T12:00:00.000Z", "config": { "secure": false, "ignoreTls": false, "requireTls": false, "auth": { "user": "username", "pass": "password" } }, "smtpConfig": { "secure": false, "ignoreTls": false, "requireTls": false, "auth": { "user": "username", "pass": "password" } } } ``` ## Errors - `400` Ungültiger Hostname oder ungültiger Request Body - `400` Ungültiger Customer-Identifier - `401` Unauthorized - `403` Forbidden (z. B. `readonly` oder global supporter)

### SMTP Monitor löschen
URL: https://docs.uptimeify.io/de/api/monitors/smtp-monitors/delete-smtp-monitor
Description: Löscht einen SMTP Monitor.
Summary: `DELETE /api/smtp-monitors/:smtpMonitorPublicId` ## Authentifizierung Erfordert eine gültige Session und Schreibrechte. - Header: `Authorization: Bearer <token>` ## Parameter - `smtpMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des SMTP Monitors. ## cURL ```bash curl -X DELETE "https://YOUR_DOMAIN/api/smtp-monitors/33333333-3333-4333-8333-333333333333" \ -H "Authorization: Bearer $TOKEN" ``` ## Response ```json { "success": true } ``` ## Errors - `400` SMTP Monitor Public ID (UUID) erforderlich - `401` Unauthorized - `403` Forbidden - `404` Not found

### SMTP Monitor abrufen
URL: https://docs.uptimeify.io/de/api/monitors/smtp-monitors/get-smtp-monitor
Description: Gibt Details zu einem SMTP Monitor zurück.
Summary: `GET /api/smtp-monitors/:smtpMonitorPublicId` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `smtpMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des SMTP Monitors. ## cURL ```bash curl "https://YOUR_DOMAIN/api/smtp-monitors/33333333-3333-4333-8333-333333333333" \ -H "Authorization: Bearer $TOKEN" ``` ## Response ```json { "id": 200, "organizationId": 1, "customerId": 10, "name": "Outbound SMTP", "hostname": "smtp.example.com", "port": 587, "status": "active", "checkInterval": 60, "timeoutSeconds": 30, "customerName": "Example Customer", "notificationEmail": null, "notificationPhoneNumber": null, "lastCheckedAt": "2026-01-01T12:00:00.000Z", "createdAt": "2026-01-01T12:00:00.000Z", "updatedAt": "2026-01-01T12:00:00.000Z", "config": { "secure": false, "ignoreTls": false, "requireTls": false }, "smtpConfig": { "secure": false, "ignoreTls": false, "requireTls": false } } ``` ## Errors - `400` SMTP Monitor Public ID (UUID) erforderlich - `401` Unauthorized - `403` Forbidden - `404` Not found

### SMTP Monitor Alert-Historie abrufen
URL: https://docs.uptimeify.io/de/api/monitors/smtp-monitors/get-smtp-monitor-alert-history
Description: Gibt die Benachrichtigungs-/Eskalationsversuche (Alert-Historie) für Vorfälle eines SMTP Monitors zurück.
Summary: `GET /api/smtp-monitors/:smtpMonitorPublicId/alert-history` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `smtpMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des SMTP Monitors. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/smtp-monitors/11111111-1111-4111-8111-111111111111/alert-history" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Beispiel-Antwort ```json { "alerts": [ { "id": 987, "incidentId": 123, "type": "slack", "status": "sent", "channelName": "Ops Slack", "sentAt": "2026-02-26T12:11:00.000Z", "errorMessage": null } ], "total": 1 } ``` Jeder Eintrag ist ein Zustellversuch an einen Benachrichtigungskanal. `status` ist `sent` oder `failed` (bei Fehler ist `errorMessage` gesetzt); `type` ist der Kanaltyp (z. B. `email`, `slack`, `opsgenie`). ## Häufige Fehler - `400 SMTP monitor public ID (UUID) required` wenn `:smtpMonitorPublicId` ungültig ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf den Monitor hast

### SMTP Monitor Check-Historie abrufen
URL: https://docs.uptimeify.io/de/api/monitors/smtp-monitors/get-smtp-monitor-check-history
Description: Gibt die letzten Check-Ergebnisse für einen SMTP Monitor zurück.
Summary: `GET /api/smtp-monitors/:smtpMonitorPublicId/check-history` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `smtpMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des SMTP Monitors. ## Query Parameter - `limit` (number, optional) - Default: `50` - Max: `200` ## cURL ```bash curl "https://YOUR_DOMAIN/api/smtp-monitors/33333333-3333-4333-8333-333333333333/check-history?limit=50" \ -H "Authorization: Bearer $TOKEN" ``` ## Response ```json { "data": [ { "id": 12345, "status": "success", "errorMessage": null, "warningMessage": null, "timingSmtp": 123, "diagnostics": { "raw": "optional diagnostic payload" }, "checkedAt": "2026-01-01T12:00:00.000Z", "locationId": 7, "locationName": "Nuremberg (DE)", "locationCode": "de-nbg" } ] } ``` ## Errors - `400` SMTP Monitor Public ID (UUID) erforderlich - `401` Unauthorized - `403` Forbidden - `404` Not found

### SMTP Monitor Details abrufen
URL: https://docs.uptimeify.io/de/api/monitors/smtp-monitors/get-smtp-monitor-details
Description: Konsolidierter Endpunkt, der die Daten für die SMTP Monitor Detailseite in einem Call zurückgibt.
Summary: `GET /api/smtp-monitors/:smtpMonitorPublicId/details` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `smtpMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des SMTP Monitors. ## Query Parameter - `range` (string, optional): `day`, `week`, `month`, `year` (Default: `day`) - `date` (string, optional): Referenzdatum (wird via `new Date(date)` geparst) - `startDate` (string, optional) - `endDate` (string, optional) - `granularity` (string, optional) - Wenn `raw`, wird Aggregation deaktiviert. ## cURL ```bash curl "https://YOUR_DOMAIN/api/smtp-monitors/33333333-3333-4333-8333-333333333333/details?range=day" \ -H "Authorization: Bearer $TOKEN" ``` ## Response Die Response ist ein einzelnes Objekt mit diesen Top-Level Keys: - `smtpMonitorId` - `monitor` - `latestCheck` - `uptimeStats` - `uptimeStatsMeta` - `monitoringData` - `incidents` - `alerts` - `testResultLog` - `maintenance` Beispiel (gekürzt): ```json { "smtpMonitorId": 200, "monitor": { "id": 200, "customerId": 10, "name": "Outbound SMTP", "hostname": "smtp.example.com", "port": 587, "status": "active", "checkInterval": 60, "timeoutSeconds": 30, "config": { "secure": false, "requireTls": true } }, "latestCheck": { "status": "success", "checkedAt": "2026-01-01T12:00:00.000Z", "timingSmtp": 123, "locationCode": "de-nbg", "locationName": "Nuremberg (DE)" }, "uptimeStats": { "day": 99.9, "month": 99.5, "year": 99.0, "dayAvgResponse": 120, "monthAvgResponse": 140, "yearAvgResponse": 150 }, "maintenance": { "inMaintenance": false, "activeWindows": [], "allWindows": [] } } ``` ## Errors - `400` Ungültige SMTP Monitor Public ID (UUID) - `401` Unauthorized - `403` Forbidden - `404` Not found - `500` Failed to fetch SMTP monitor details

### SMTP Monitor Ausfall-Historie abrufen
URL: https://docs.uptimeify.io/de/api/monitors/smtp-monitors/get-smtp-monitor-incident-history
Description: Gibt die Vorfälle eines einzelnen SMTP Monitors zurück (die letzten 100), inklusive berechneter Dauer.
Summary: `GET /api/smtp-monitors/:smtpMonitorPublicId/incident-history` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `smtpMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des SMTP Monitors. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/smtp-monitors/11111111-1111-4111-8111-111111111111/incident-history" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Beispiel-Antwort ```json { "incidents": [ { "id": 123, "type": "downtime", "status": "resolved", "startedAt": "Feb 26, 2026, 12:10:00", "endedAt": "Feb 26, 2026, 12:12:30", "duration": "2m 30s" } ], "total": 1 } ``` `type` spiegelt die Fehlerkategorie dieses Monitors wider; `status` ist `active` (laufend) oder `resolved`. Laufende Vorfälle haben ein `null` bei `endedAt`. ## Häufige Fehler - `400 SMTP monitor public ID (UUID) required` wenn `:smtpMonitorPublicId` ungültig ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf den Monitor hast

### SMTP Monitore auflisten
URL: https://docs.uptimeify.io/de/api/monitors/smtp-monitors/list-smtp-monitors
Description: Listet SMTP Monitore einer Organisation auf.
Summary: `GET /api/smtp-monitors` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `organizationId` (Query, optional): Organisations-ID. Default ist die Organisation des aktuellen Nutzers. - `customerId` (Query, optional): Nach Kunden-ID filtern. - `search` (Query, optional): Suche nach Name, Hostname oder Kunde. - `page` (Query, optional): Seite (Default: 1). - `perPage` (Query, optional): Einträge pro Seite (Default: 50, Max: 200). ## cURL ```bash curl "https://YOUR_DOMAIN/api/smtp-monitors?page=1&perPage=50" \ -H "Authorization: Bearer $TOKEN" ``` ## Response ```json { "items": [ { "id": 200, "organizationId": 1, "customerId": 10, "name": "Outbound SMTP", "hostname": "smtp.example.com", "port": 587, "status": "active", "checkInterval": 60, "timeoutSeconds": 30, "customerName": "Example Customer", "notificationEmail": null, "notificationPhoneNumber": null, "lastCheckedAt": "2026-01-01T12:00:00.000Z", "createdAt": "2026-01-01T12:00:00.000Z", "updatedAt": "2026-01-01T12:00:00.000Z", "config": { "secure": false, "ignoreTls": false, "requireTls": false } } ], "total": 1, "page": 1, "perPage": 50 } ``` ## Errors - `400` Ungültige `organizationId` oder `customerId` - `401` Unauthorized - `403` Forbidden

### Check für SMTP Monitor triggern
URL: https://docs.uptimeify.io/de/api/monitors/smtp-monitors/trigger-check-smtp-monitor
Description: Startet einen sofortigen Check von allen zulässigen Monitoring-Standorten.
Summary: `POST /api/smtp-monitors/:smtpMonitorPublicId/trigger-check` ## Authentifizierung Erfordert eine gültige Session und Schreibrechte. - Header: `Authorization: Bearer <token>` ## Parameter - `smtpMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des SMTP Monitors. ## cURL ```bash curl -X POST "https://YOUR_DOMAIN/api/smtp-monitors/33333333-3333-4333-8333-333333333333/trigger-check" \ -H "Authorization: Bearer $TOKEN" ``` ## Response ```json { "success": true, "message": "Checks triggered successfully", "smtpMonitorId": 200, "locationCodes": ["de-nbg", "fi-hel"], "queueNames": ["smtp-monitor-checks-de-nbg", "smtp-monitor-checks-fi-hel"] } ``` ## Errors - `400` SMTP Monitor Public ID (UUID) erforderlich - `401` Unauthorized - `403` Forbidden - `404` Not found - `500` Failed to trigger check (die Status-Message kann z. B. "No active monitoring locations available" enthalten)

### SMTP Monitor aktualisieren
URL: https://docs.uptimeify.io/de/api/monitors/smtp-monitors/update-smtp-monitor
Description: Aktualisiert einen SMTP Monitor.
Summary: `PATCH /api/smtp-monitors/:smtpMonitorPublicId` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `smtpMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des SMTP Monitors. ## Request Body Alle Felder sind optional. ```json { "name": "Outbound SMTP (Primary)", "hostname": "smtp.example.com", "port": 587, "status": "paused", "checkInterval": 60, "timeoutSeconds": 30, "allowedCheckCountryCodes": ["de", "ch"], "smtpConfig": { "secure": false, "requireTls": true, "auth": { "user": "username", "pass": "password" } } } ``` ### Hinweise - `status` akzeptiert `active`, `maintenance`, `disabled`, `paused`, `inactive`. - `paused` und `inactive` werden zu `disabled` normalisiert. - `allowedCheckCountryCodes` wird zu Uppercase ISO Codes normalisiert (z. B. `DE`, `US`). Leere Listen werden `null`. - SMTP Config kann als `smtpConfig` oder als `config` (Alias) übergeben werden. Wenn beides fehlt, bleibt die gespeicherte Config unverändert. - Nutzer mit Rolle `readonly` dürfen nur `status` ändern. ## cURL ```bash curl -X PATCH "https://YOUR_DOMAIN/api/smtp-monitors/33333333-3333-4333-8333-333333333333" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "status": "disabled" }' ``` ## Response ```json { "id": 200, "organizationId": 1, "customerId": 10, "name": "Outbound SMTP (Primary)", "hostname": "smtp.example.com", "port": 587, "status": "disabled", "checkInterval": 60, "timeoutSeconds": 30, "notificationEmail": null, "notificationPhoneNumber": null, "lastCheckedAt": "2026-01-01T12:00:00.000Z", "createdAt": "2026-01-01T12:00:00.000Z", "updatedAt": "2026-01-01T12:01:00.000Z", "config": { "secure": false, "requireTls": true, "auth": { "user": "username", "pass": "password" } }, "smtpConfig": { "secure": false, "requireTls": true, "auth": { "user": "username", "pass": "password" } } } ``` ## Errors - `400` SMTP Monitor Public ID (UUID) erforderlich - `401` Unauthorized - `403` Forbidden (readonly Nutzer dürfen nur `status` ändern; global supporters dürfen nicht aktualisieren) - `404` Not found

### SSH Monitore
URL: https://docs.uptimeify.io/de/api/monitors/ssh-monitors
Description: Verwalte SSH Monitore.
Summary: Pfadbasierte SSH-Monitor-Endpunkte verwenden `sshMonitorPublicId`-UUIDs. ## Endpunkte - [SSH Monitore auflisten](./ssh-monitore-auflisten) - [SSH Monitor erstellen](./ssh-monitor-erstellen) - [SSH Monitor abrufen](./ssh-monitor-abrufen) - [SSH Monitor Details abrufen](./ssh-monitor-details-abrufen) - [SSH Monitor Check Historie abrufen](./ssh-monitor-check-historie-abrufen) - [SSH Monitor aktualisieren](./ssh-monitor-aktualisieren-status) - [SSH Monitor löschen](./ssh-monitor-loeschen) - [SSH Check triggern](./ssh-monitor-check-triggern)

### SSH Monitor erstellen
URL: https://docs.uptimeify.io/de/api/monitors/ssh-monitors/create-ssh-monitor
Description: Erstellt einen neuen SSH Monitor.
Summary: `POST /api/ssh-monitors` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Request Body ```json { "customerId": "11111111-1111-4111-8111-111111111111", "name": "Bastion Host", "hostname": "ssh.example.com", "port": 22, "status": "active", "checkInterval": 60, "timeoutSeconds": 30, "sshConfig": { "username": "root", "password": "password", "privateKey": "-----BEGIN OPENSSH PRIVATE KEY-----..." } } ``` ### Felder - `customerId` (number | string, required) - Akzeptiert entweder die interne numerische Kunden-ID oder die öffentliche Kunden-UUID. - `name` (string, required) - `hostname` (string, required) - Muss ein Hostname sein (kein Protokoll wie `https://`, kein Pfad wie `/ssh`). - `port` (number | null, optional) - Wenn weggelassen oder `null`, nutzt der Worker standardmäßig Port `22`. - `status` (string, optional) - Erlaubt: `active`, `maintenance`, `disabled`, `paused`, `inactive` - `checkInterval` (number, optional) - `timeoutSeconds` (number, optional) - `sshConfig` (object, optional) - Wird als `config` JSON gespeichert. ### `sshConfig` (vom Worker unterstützte Keys) - `username` (string) - Wenn weggelassen, nutzt der Worker `anonymous`. - `password` (string) - `privateKey` (string) ## cURL ```bash curl -X POST "https://YOUR_DOMAIN/api/ssh-monitors" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "customerId": "11111111-1111-4111-8111-111111111111", "name": "Bastion Host", "hostname": "ssh.example.com", "port": 22, "status": "active", "checkInterval": 60, "timeoutSeconds": 30, "sshConfig": { "username": "root", "password": "password" } }' ``` ## Response ```json { "id": 300, "organizationId": 1, "customerId": 10, "name": "Bastion Host", "hostname": "ssh.example.com", "port": 22, "status": "active", "checkInterval": 60, "timeoutSeconds": 30, "notificationEmail": null, "notificationPhoneNumber": null, "lastCheckedAt": null, "createdAt": "2026-02-26T12:00:00.000Z", "updatedAt": "2026-02-26T12:00:00.000Z", "config": { "username": "root", "password": "password" }, "sshConfig": { "username": "root", "password": "password" } } ``` ## Errors - `400` Ungültiger Hostname oder ungültiger Request Body - `400` Ungültiger Customer-Identifier - `401` Unauthorized - `403` Forbidden (z.B. `readonly` oder global supporter)

### SSH Monitor löschen
URL: https://docs.uptimeify.io/de/api/monitors/ssh-monitors/delete-ssh-monitor
Description: Löscht einen SSH Monitor.
Summary: `DELETE /api/ssh-monitors/:sshMonitorPublicId` ## Authentifizierung Erfordert eine gültige Session und Schreibrechte. - Header: `Authorization: Bearer <token>` ## Parameter - `sshMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des SSH Monitors. ## cURL ```bash curl -X DELETE "https://YOUR_DOMAIN/api/ssh-monitors/44444444-4444-4444-8444-444444444444" \ -H "Authorization: Bearer $TOKEN" ``` ## Response ```json { "success": true } ``` ## Errors - `400` SSH Monitor Public ID (UUID) erforderlich - `401` Unauthorized - `403` Forbidden - `404` Not found

### SSH Monitor abrufen
URL: https://docs.uptimeify.io/de/api/monitors/ssh-monitors/get-ssh-monitor
Description: Gibt Details zu einem SSH Monitor zurück.
Summary: `GET /api/ssh-monitors/:sshMonitorPublicId` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `sshMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des SSH Monitors. ## cURL ```bash curl "https://YOUR_DOMAIN/api/ssh-monitors/44444444-4444-4444-8444-444444444444" \ -H "Authorization: Bearer $TOKEN" ``` ## Response ```json { "id": 300, "organizationId": 1, "customerId": 10, "name": "Bastion Host", "hostname": "ssh.example.com", "port": 22, "status": "active", "checkInterval": 60, "timeoutSeconds": 30, "customerName": "Example Customer", "notificationEmail": null, "notificationPhoneNumber": null, "lastCheckedAt": "2026-02-26T12:00:00.000Z", "createdAt": "2026-02-26T12:00:00.000Z", "updatedAt": "2026-02-26T12:00:00.000Z", "config": { "username": "root" }, "sshConfig": { "username": "root" } } ``` ## Errors - `400` SSH Monitor Public ID (UUID) erforderlich - `401` Unauthorized - `403` Forbidden - `404` Not found

### SSH Monitor Alert-Historie abrufen
URL: https://docs.uptimeify.io/de/api/monitors/ssh-monitors/get-ssh-monitor-alert-history
Description: Gibt die Benachrichtigungs-/Eskalationsversuche (Alert-Historie) für Vorfälle eines SSH Monitors zurück.
Summary: `GET /api/ssh-monitors/:sshMonitorPublicId/alert-history` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `sshMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des SSH Monitors. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/ssh-monitors/11111111-1111-4111-8111-111111111111/alert-history" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Beispiel-Antwort ```json { "alerts": [ { "id": 987, "incidentId": 123, "type": "slack", "status": "sent", "channelName": "Ops Slack", "sentAt": "2026-02-26T12:11:00.000Z", "errorMessage": null } ], "total": 1 } ``` Jeder Eintrag ist ein Zustellversuch an einen Benachrichtigungskanal. `status` ist `sent` oder `failed` (bei Fehler ist `errorMessage` gesetzt); `type` ist der Kanaltyp (z. B. `email`, `slack`, `opsgenie`). ## Häufige Fehler - `400 SSH monitor public ID (UUID) required` wenn `:sshMonitorPublicId` ungültig ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf den Monitor hast

### SSH Monitor Check Historie abrufen
URL: https://docs.uptimeify.io/de/api/monitors/ssh-monitors/get-ssh-monitor-check-history
Description: Gibt die letzten Check-Ergebnisse für einen SSH Monitor zurück.
Summary: `GET /api/ssh-monitors/:sshMonitorPublicId/check-history` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `sshMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des SSH Monitors. ## Query Parameter - `limit` (number, optional) - Default: `50` - Max: `200` ## cURL ```bash curl "https://YOUR_DOMAIN/api/ssh-monitors/44444444-4444-4444-8444-444444444444/check-history?limit=50" \ -H "Authorization: Bearer $TOKEN" ``` ## Response ```json { "data": [ { "id": 12345, "status": "success", "errorMessage": null, "warningMessage": null, "timingSsh": 123, "diagnostics": { "message": "SSH connection successful" }, "checkedAt": "2026-02-26T12:00:00.000Z", "locationId": 7, "locationName": "Nuremberg (DE)", "locationCode": "de-nbg" } ] } ``` ## Errors - `400` SSH Monitor Public ID (UUID) erforderlich - `401` Unauthorized - `403` Forbidden - `404` Not found

### SSH Monitor Details abrufen
URL: https://docs.uptimeify.io/de/api/monitors/ssh-monitors/get-ssh-monitor-details
Description: Konsolidierter Endpunkt, der die Daten für die SSH Monitor Detailseite in einem Call zurückgibt.
Summary: `GET /api/ssh-monitors/:sshMonitorPublicId/details` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `sshMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des SSH Monitors. ## Query Parameter - `range` (string, optional): `day`, `week`, `month`, `year` (Default: `day`) - `date` (string, optional): Referenzdatum (wird via `new Date(date)` geparst) - `startDate` (string, optional) - `endDate` (string, optional) - `granularity` (string, optional) - Wenn `raw`, wird Aggregation deaktiviert. ## cURL ```bash curl "https://YOUR_DOMAIN/api/ssh-monitors/44444444-4444-4444-8444-444444444444/details?range=day" \ -H "Authorization: Bearer $TOKEN" ``` ## Response Die Response ist ein einzelnes Objekt mit diesen Top-Level Keys: - `sshMonitorId` - `monitor` - `latestCheck` - `uptimeStats` - `uptimeStatsMeta` - `monitoringData` - `incidents` - `alerts` - `testResultLog` - `maintenance` Beispiel (gekürzt): ```json { "sshMonitorId": 300, "monitor": { "id": 300, "customerId": 10, "name": "Bastion Host", "hostname": "ssh.example.com", "port": 22, "status": "active", "checkInterval": 60, "timeoutSeconds": 30, "config": { "username": "root" } }, "latestCheck": { "status": "success", "checkedAt": "2026-02-26T12:00:00.000Z", "timingSsh": 123, "locationCode": "de-nbg", "locationName": "Nuremberg (DE)" }, "uptimeStats": { "day": 99.9, "month": 99.5, "year": 99.0, "dayAvgResponse": 120, "monthAvgResponse": 140, "yearAvgResponse": 150 }, "maintenance": { "inMaintenance": false, "activeWindows": [], "allWindows": [] } } ``` ## Errors - `400` Ungültige SSH Monitor Public ID (UUID) - `401` Unauthorized - `403` Forbidden - `404` Not found - `500` Failed to fetch SSH monitor details

### SSH Monitor Ausfall-Historie abrufen
URL: https://docs.uptimeify.io/de/api/monitors/ssh-monitors/get-ssh-monitor-incident-history
Description: Gibt die Vorfälle eines einzelnen SSH Monitors zurück (die letzten 100), inklusive berechneter Dauer.
Summary: `GET /api/ssh-monitors/:sshMonitorPublicId/incident-history` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `sshMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des SSH Monitors. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/ssh-monitors/11111111-1111-4111-8111-111111111111/incident-history" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Beispiel-Antwort ```json { "incidents": [ { "id": 123, "type": "downtime", "status": "resolved", "startedAt": "Feb 26, 2026, 12:10:00", "endedAt": "Feb 26, 2026, 12:12:30", "duration": "2m 30s" } ], "total": 1 } ``` `type` spiegelt die Fehlerkategorie dieses Monitors wider; `status` ist `active` (laufend) oder `resolved`. Laufende Vorfälle haben ein `null` bei `endedAt`. ## Häufige Fehler - `400 SSH monitor public ID (UUID) required` wenn `:sshMonitorPublicId` ungültig ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf den Monitor hast

### SSH Monitore auflisten
URL: https://docs.uptimeify.io/de/api/monitors/ssh-monitors/list-ssh-monitors
Description: Listet SSH Monitore einer Organisation auf.
Summary: `GET /api/ssh-monitors` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `organizationId` (Query, optional): Organisations-ID. Default ist die Organisation des aktuellen Nutzers. - `customerId` (Query, optional): Nach Kunden-ID filtern. - `search` (Query, optional): Suche nach Name, Hostname oder Kunde. - `page` (Query, optional): Seite (Default: 1). - `perPage` (Query, optional): Einträge pro Seite (Default: 50, Max: 200). ## cURL ```bash curl "https://YOUR_DOMAIN/api/ssh-monitors?page=1&perPage=50" \ -H "Authorization: Bearer $TOKEN" ``` ## Response ```json { "items": [ { "id": 300, "organizationId": 1, "customerId": 10, "name": "Bastion Host", "hostname": "ssh.example.com", "port": 22, "status": "active", "checkInterval": 60, "timeoutSeconds": 30, "customerName": "Example Customer", "notificationEmail": null, "notificationPhoneNumber": null, "lastCheckedAt": "2026-02-26T12:00:00.000Z", "createdAt": "2026-02-26T12:00:00.000Z", "updatedAt": "2026-02-26T12:00:00.000Z", "config": { "username": "root" } } ], "total": 1, "page": 1, "perPage": 50 } ``` ## Errors - `400` Ungültige `organizationId` oder `customerId` - `401` Unauthorized - `403` Forbidden

### SSH Check triggern
URL: https://docs.uptimeify.io/de/api/monitors/ssh-monitors/trigger-check-ssh-monitor
Description: Startet einen sofortigen Check von allen zulässigen Monitoring-Standorten.
Summary: `POST /api/ssh-monitors/:sshMonitorPublicId/trigger-check` ## Authentifizierung Erfordert eine gültige Session und Schreibrechte. - Header: `Authorization: Bearer <token>` ## Parameter - `sshMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des SSH Monitors. ## cURL ```bash curl -X POST "https://YOUR_DOMAIN/api/ssh-monitors/44444444-4444-4444-8444-444444444444/trigger-check" \ -H "Authorization: Bearer $TOKEN" ``` ## Response ```json { "success": true, "message": "Checks triggered successfully", "sshMonitorId": 300, "locationCodes": ["de-nbg", "fi-hel"], "queueNames": ["ssh-monitor-checks-de-nbg", "ssh-monitor-checks-fi-hel"] } ``` ## Errors - `400` SSH Monitor Public ID (UUID) erforderlich - `401` Unauthorized - `403` Forbidden - `404` Not found - `500` Failed to trigger check (die StatusMessage kann z.B. "No active monitoring locations available" enthalten)

### SSH Monitor aktualisieren
URL: https://docs.uptimeify.io/de/api/monitors/ssh-monitors/update-ssh-monitor
Description: Aktualisiert einen SSH Monitor und/oder ändert den Status.
Summary: `PATCH /api/ssh-monitors/:sshMonitorPublicId` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Parameter - `sshMonitorPublicId` (Pfad, erforderlich): Öffentliche UUID des SSH Monitors. ## Request Body Alle Felder sind optional. ```json { "name": "Bastion Host (Primary)", "hostname": "ssh.example.com", "port": 22, "status": "paused", "checkInterval": 60, "timeoutSeconds": 30, "allowedCheckCountryCodes": ["de", "ch"], "sshConfig": { "username": "root", "privateKey": "-----BEGIN OPENSSH PRIVATE KEY-----..." } } ``` ### Hinweise - `status` akzeptiert `active`, `maintenance`, `disabled`, `paused`, `inactive`. - `paused` und `inactive` werden zu `disabled` normalisiert. - `allowedCheckCountryCodes` wird zu Uppercase ISO Codes normalisiert (z.B. `DE`, `US`). Leere Listen werden zu `null`. - SSH Config kann als `sshConfig` oder als `config` (Alias) übergeben werden. Wenn keiner der Keys vorhanden ist, bleibt die gespeicherte Config unverändert. - Nutzer mit Rolle `readonly` können nur `status` ändern. ## cURL ```bash curl -X PATCH "https://YOUR_DOMAIN/api/ssh-monitors/44444444-4444-4444-8444-444444444444" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "status": "disabled" }' ``` ## Response ```json { "id": 300, "organizationId": 1, "customerId": 10, "name": "Bastion Host (Primary)", "hostname": "ssh.example.com", "port": 22, "status": "disabled", "checkInterval": 60, "timeoutSeconds": 30, "notificationEmail": null, "notificationPhoneNumber": null, "lastCheckedAt": "2026-02-26T12:00:00.000Z", "createdAt": "2026-02-26T12:00:00.000Z", "updatedAt": "2026-02-26T12:01:00.000Z", "config": { "username": "root" }, "sshConfig": { "username": "root" } } ``` ## Errors - `400` SSH Monitor Public ID (UUID) erforderlich / ungültige Felder - `401` Unauthorized - `403` Forbidden (readonly darf nur `status` ändern; global supporters dürfen nicht updaten) - `404` Not found

### Benachrichtigungskanäle
URL: https://docs.uptimeify.io/de/api/notification-channels
Description: 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.
Summary: ## Authentifizierung Alle Beispiele setzen einen Bearer-Token voraus: ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" ``` ## Kanaltypen und Config Jeder Kanaltyp hat eine spezifische `config`-Struktur: | Type | Config Fields | Notes | |------|--------------|-------| | `email` | `{ email, to }` | E-Mail-Adresse und Empfängername | | `sms` | `{ phoneNumber }` | Telefonnummer im internationalen Format | | `webhook` | `{ url, method?, headers?, bodyTemplate?, timeout?, retryAttempts?, retryDelay?, expectedStatusCodes?, secret? }` | HTTP-Webhook. `secret` für HMAC-Signierung | | `slack` | `{ secret }` | Slack Incoming-Webhook-URL | | `discord` | `{ secret }` | Discord Incoming-Webhook-URL | | `pagerduty` | `{ routingKey }` | PagerDuty Events API v2 Routing-Key | | `pushover` | `{ userKey, apiToken }` | Pushover User-Key und API-Token | | `opsgenie` | `{ apiKey }` | Opsgenie API-Key | Geheimnisse (Webhook-`secret`, Slack-/Discord-URLs, PagerDuty-Routing-Keys, Pushover-Zugangsdaten, Opsgenie-API-Keys) werden **verschlüsselt gespeichert** und **in API-Antworten unkenntlich gemacht** (durch `null` ersetzt, mit `hasSecret: true`-Flags). ## Webhook-Signaturprüfung Wenn auf einem Webhook-Kanal ein `secret` konfiguriert ist, signiert Uptimeify ausgehende Payloads, damit Empfänger die Authentizität verifizieren können. **Algorithmus:** HMAC-SHA256 **Header:** `X-Webhook-Signature` — hex-kodierter HMAC-SHA256-Digest **Begleitende Header, die mit jedem Webhook gesendet werden:** | Header | Value | |--------|-------| | `X-Webhook-Signature` | Hex-kodierter HMAC-SHA256-Digest | | `X-Webhook-Signature-Algorithm` | `sha256` | | `X-Webhook-Timestamp` | ISO-8601-Zeitstempel (z. B. `2026-05-05T12:00:00.000Z`) | | `X-Webhook-Attempt` | 1-basierte Retry-Nummer (z. B. `1`, `2`, `3`) | | `X-Webhook-Event` | Event-Typ: `alert`, `recovery` oder `dnsbl` | **Verifizierungsschritte:** 1. Lies den rohen Request-Body als String (nicht zuerst als JSON parsen). 2. Berechne HMAC-SHA256 mit dem im Kanal konfigurierten `secret` als Schlüssel und dem rohen Body-String als Nachricht. 3. Vergleiche das Ergebnis (hex-kodiert) mit dem Wert des `X-Webhook-Signature`-Headers per konstanter Laufzeit-Vergleich (constant-time comparison). 4. Optional kannst du `X-Webhook-Timestamp` für Replay-Schutz prüfen. ```javascript // Node.js verification example const crypto = require('crypto') function verifySignature(rawBody, signature, secret) { const expected = crypto .createHmac('sha256', secret) .update(rawBody) .digest('hex') return crypto.timingSafeEqual( Buffer.from(signature), Buffer.from(expected) ) } ``` ```python # Python verification example def verify_signature(raw_body, signature, secret): expected = hmac.new( secret.encode('utf-8'), raw_body.encode('utf-8'), hashlib.sha256 ).hexdigest() return hmac.compare_digest(signature, expected) ``` ## Scope-Auflösung Beim Auflisten von Kanälen bestimmt der Scope, welche Kanäle zurückgegeben werden: - **Organisationsebene** (nur `organizationId`, kein `customerId`/`websiteId`): Standardkanäle für alle Kunden - **Kundenebene** (`customerId` gesetzt, kein `websiteId`): Kundenspezifische Overrides - **Website-Ebene** (`websiteId` gesetzt): Overrides pro Monitor ## Endpunkte - [Benachrichtigungskanäle auflisten](./list-notification-channels) - [Benachrichtigungskanal erstellen](./create-notification-channel) - [Benachrichtigungskanal aktualisieren](./update-notification-channel) - [Benachrichtigungskanal löschen](./delete-notification-channel) - [Benachrichtigungskanal testen](./test-notification-channel)

### Benachrichtigungskanal erstellen
URL: https://docs.uptimeify.io/de/api/notification-channels/create-notification-channel
Description: Erstellt einen neuen Benachrichtigungskanal. Geheimnisse in config werden serverseitig verschlüsselt.
Summary: `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"`): `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](/de/integrations), was jeder Kanal benötigt. Du kannst einen Kanal vor dem Speichern mit dem Endpunkt [Benachrichtigungskanal testen](/de/api/notification-channels/test-notification-channel) validieren. ## Beispiel (cURL) — E-Mail-Kanal ```bash 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@example.com", "to": "Ops Team" }, "organizationId": 1 }' ``` ## Beispiel (cURL) — Slack-Kanal ```bash 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 ```bash 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://example.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](/de/api/error-codes-and-known-pitfalls) für Fehlerantworten.

### Benachrichtigungskanal löschen
URL: https://docs.uptimeify.io/de/api/notification-channels/delete-notification-channel
Description: Löscht einen Benachrichtigungskanal. War der Kanal ein Standard auf Organisationsebene, werden die Organisations-Standards automatisch synchronisiert.
Summary: `DELETE /api/notification-channels/:id` ## Beispiel (cURL) ```bash curl -X DELETE "$BASE_URL/api/notification-channels/1" \ -H "Authorization: Bearer $TOKEN" ``` ## Antwort (Response) ```json { "success": true } ``` ## Häufige Fehler - `401 Unauthorized` wenn du nicht authentifiziert bist - `403 Forbidden` wenn du auf Kanäle außerhalb deines Scopes zugreifst - `404 Not found` wenn der Kanal nicht existiert

### Benachrichtigungskanäle auflisten
URL: https://docs.uptimeify.io/de/api/notification-channels/list-notification-channels
Description: Gibt Benachrichtigungskanäle zurück, gescoped nach Organisation, Kunde oder Website.
Summary: `GET /api/notification-channels` ## Query Parameter | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `organizationId` | number | Nein | Scope auf Organisation | | `customerId` | number | Nein | Scope auf Kunde | | `websiteId` | number | Nein | Scope auf Website (inklusive Organisations- + Kundenkanäle) | ## Beispiel (cURL) ```bash curl -X GET "$BASE_URL/api/notification-channels?organizationId=1" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Antwort (Response) ```json [ { "id": 1, "organizationId": 1, "customerId": null, "websiteId": null, "type": "email", "category": "direct", "name": "Ops Email", "config": { "email": "ops@example.com", "to": "Ops Team" }, "priority": 1, "delaySeconds": 0, "conditions": null, "isActive": true, "allowedPackageTypes": null } ] ``` ## Häufige Fehler - `401 Unauthorized` wenn du nicht authentifiziert bist - `403 Forbidden` wenn du auf Kanäle außerhalb deines Scopes zugreifst

### Benachrichtigungskanal testen
URL: https://docs.uptimeify.io/de/api/notification-channels/test-notification-channel
Description: Testet die Konfiguration eines Benachrichtigungskanals. Sendet optional eine echte Testnachricht.
Summary: `POST /api/notification-channels/test` ## Anfrage (Request Body) | Field | Type | Required | Default | Description | |-------|------|----------|---------|-------------| | `type` | string | Ja | — | `webhook`, `slack`, `discord`, `pagerduty`, `pushover`, `opsgenie` | | `config` | object | Ja | `{}` | Kanal-Config mit Geheimnissen | | `organizationId` | number | Nein | aus Session | Organisations-Scope | | `customerId` | number | Nein | null | Kunden-Scope | | `websiteId` | number | Nein | null | Website-Scope | | `dryRun` | boolean | Nein | false | Falls true, wird nur validiert (kein tatsächliches Senden) | ## Beispiel (cURL) ```bash curl -X POST "$BASE_URL/api/notification-channels/test" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "type": "webhook", "config": { "url": "https://example.com/webhook", "method": "POST", "timeout": 15 }, "dryRun": false }' ``` ## Antwort (Response) ```json { "success": true, "mode": "send", "message": "Webhook delivered successfully", "validation": { "ok": true, "errors": [], "warnings": [] }, "request": { "url": "https://example.com/webhook", "method": "POST", "timeoutSeconds": 15, "headers": {}, "bodyPreview": "...", "bodySize": 256 }, "response": { "reachable": true, "ok": true, "statusCode": 200, "statusText": "OK", "durationMs": 150, "headers": {}, "bodyPreview": null, "bodySize": null } } ``` HTTP-429-Antworten werden als „erreichbar, aber rate-limitiert" behandelt (success: true). ## Häufige Fehler - `401 Unauthorized` wenn du nicht authentifiziert bist - `400 Bad Request` wenn die Config für den angegebenen Typ ungültig ist

### Benachrichtigungskanal aktualisieren
URL: https://docs.uptimeify.io/de/api/notification-channels/update-notification-channel
Description: Aktualisiert einen Benachrichtigungskanal.
Summary: `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. ## Anfrage (Request Body) (alle optional) | Field | Type | Description | |-------|------|-------------| | `type` | string | Kanaltyp | | `name` | string | Anzeigename | | `config` | object\|string | Mit bestehenden Geheimnissen zusammengeführt | | `priority` | number | Prioritätsreihenfolge | | `delaySeconds` | number | Verzögerung vor dem Senden | | `conditions` | object\|string\|null | Alert-Bedingungen | | `allowedPackageTypes` | string[]\|null | Pakettypen, auf die dieser Kanal angewendet wird | | `isActive` | boolean | Ob der Kanal aktiv ist | ## Beispiel (cURL) ```bash 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 - `401 Unauthorized` wenn du nicht authentifiziert bist - `403 Forbidden` wenn du auf Kanäle außerhalb deines Scopes zugreifst - `404 Not found` wenn der Kanal nicht existiert ## Antwort (Response) Gibt das aktualisierte Benachrichtigungskanal-Objekt zurück. Siehe [Fehlercodes](/de/api/error-codes-and-known-pitfalls) für Fehlerantworten.

### Organisation & Abrechnung
URL: https://docs.uptimeify.io/de/api/organization
Description: Pfadbasierte Organisations-Endpunkte verwenden organizationPublicId-UUIDs.
Summary: ## Endpunkte - [Organisations-Details abrufen](./organisation-details-abfragen) - [Organisation aktualisieren](./organisation-aktualisieren) - [Paket-Konfigurationen auflisten](./paket-konfigurationen-auflisten) - [Paket-Konfiguration erstellen/aktualisieren](./paket-konfiguration-upsert) - [Paket-Konfiguration löschen](./paket-konfiguration-loeschen) - [Rechnungs-Details abrufen](./rechnung-details-abfragen) - [Rechnungs-Details aktualisieren](./rechnung-details-aktualisieren) - [Rechnungen auflisten](./rechnungen-auflisten) - [Fehlerliste und bekannte API-Fallen](/de/api/error-codes-and-known-pitfalls)

### Organisations-SMTP
URL: https://docs.uptimeify.io/de/api/organization-smtp
Description: Konfiguriere eigene SMTP-Einstellungen, damit die Benachrichtigungs-E-Mails deiner Organisation über deinen eigenen Mailserver versendet werden. Alle SMTP-Endpunkte erfordern die Admin-Rolle.
Summary: ## Authentifizierung Alle Endpunkte akzeptieren API-Bearer-Tokens oder Session-Cookies: ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" ``` ## Endpunkte - [SMTP-Verbindung testen](./test-smtp) - [SMTP-Versandprotokolle abrufen](./get-smtp-logs)

### SMTP-Versandprotokolle abrufen
URL: https://docs.uptimeify.io/de/api/organization-smtp/get-smtp-logs
Description: Gibt die letzten SMTP-Versandereignis-Logs aus Redis zurück. Nur für Admins.
Summary: `GET /api/organization/smtp/logs` ## Query Parameter | Parameter | Type | Default | Description | |-----------|------|---------|-------------| | `limit` | number | 100 | Maximale Anzahl zurückzugebender Ereignisse (1–500) | ## Beispiel (cURL) ```bash curl -X GET "$BASE_URL/api/organization/smtp/logs?limit=50" \ -H "Cookie: $SESSION_COOKIE" \ -H "Accept: application/json" ``` ## Antwort (Response) ```json { "events": [ { "type": "smtp_send", "timestamp": "2026-04-15T12:00:00.000Z", "to": "admin@example.com", "subject": "Website Down: example.com", "status": "sent" } ] } ``` Gibt `{ "events": [] }` zurück, wenn keine Logs vorhanden sind oder bei Redis-Fehlern (fail-open). ## Häufige Fehler - `401 Unauthorized` wenn du nicht authentifiziert bist - `403 Forbidden` wenn du kein Admin bist

### SMTP-Verbindung testen
URL: https://docs.uptimeify.io/de/api/organization-smtp/test-smtp
Description: Testet die SMTP-Konfiguration durch Versand einer Test-E-Mail. Alle Parameter sind optional — wenn weggelassen, werden die gespeicherten Konfigurationswerte verwendet. So kannst du neue Zugangsdaten testen, bevor du sie speicherst. Nur für Admins.
Summary: `POST /api/organization/smtp/test` Der Test aktualisiert außerdem die Felder `lastTestedAt`, `lastTestStatus` und `lastTestError` der SMTP-Konfiguration. ## Anfrage (Request Body) — alle optional | Field | Type | Description | |-------|------|-------------| | `toEmail` | string | Empfänger-E-Mail-Adresse (max. 320 Zeichen). Standardwert ist die E-Mail des aktuellen Benutzers. | | `subject` | string | E-Mail-Betreff (1–200 Zeichen). Standardwert ist `SMTP Test (<timestamp>)`. | | `message` | string | E-Mail-Text (1–2000 Zeichen). Standardwert ist eine Standard-Testnachricht. | | `host` | string\|null | SMTP-Server-Hostname (1–255 Zeichen). Überschreibt die gespeicherte Konfiguration. | | `port` | number\|null | SMTP-Server-Port (1–65535). Überschreibt die gespeicherte Konfiguration. | | `username` | string\|null | SMTP-Benutzername (1–200 Zeichen). Überschreibt die gespeicherte Konfiguration. | | `password` | string\|null | SMTP-Passwort (1–500 Zeichen). Überschreibt die gespeicherte Konfiguration (wird nicht gespeichert). | | `tlsMode` | string\|null | `ssl`, `starttls` oder `none`. Überschreibt die gespeicherte Konfiguration. | | `fromName` | string\|null | Anzeigename des Absenders (1–200 Zeichen). Überschreibt die gespeicherte Konfiguration. | | `fromEmail` | string\|null | Absender-E-Mail-Adresse (max. 320 Zeichen). Überschreibt die gespeicherte Konfiguration. | | `replyTo` | string\|null | Reply-To-E-Mail-Adresse (max. 320 Zeichen). Überschreibt die gespeicherte Konfiguration. | ## Beispiel (cURL) — Mit gespeicherter Konfiguration ```bash curl -X POST "$BASE_URL/api/organization/smtp/test" \ -H "Cookie: $SESSION_COOKIE" \ -H "Content-Type: application/json" \ -d '{}' ``` ## Beispiel (cURL) — Neue Zugangsdaten testen ```bash curl -X POST "$BASE_URL/api/organization/smtp/test" \ -H "Cookie: $SESSION_COOKIE" \ -H "Content-Type: application/json" \ -d '{ "host": "smtp.example.com", "port": 587, "tlsMode": "starttls", "username": "alerts@example.com", "password": "secret-password", "fromName": "Uptimeify Alerts", "fromEmail": "alerts@example.com", "toEmail": "admin@example.com" }' ``` ## Antwort (Erfolg) ```json { "success": true, "messageId": "<abc123@mail.example.com>" } ``` ## Häufige Fehler - `400 Missing recipient email (toEmail)` wenn kein Empfänger angegeben ist und der Benutzer keine E-Mail hat - `400 SMTP config incomplete (host/port required)` wenn Host oder Port fehlt - `400 SMTP config incomplete (username required)` wenn ein Benutzername benötigt wird, aber fehlt - `400 SMTP password missing (username is set)` wenn ein Passwort benötigt wird, aber fehlt - `400 SMTP config incomplete (fromEmail required)` wenn fromEmail fehlt - `403 Forbidden` wenn du kein Admin bist - `502 Failed to send SMTP test email` wenn die SMTP-Verbindung fehlschlägt

### Paket-Konfiguration löschen
URL: https://docs.uptimeify.io/de/api/organization/delete-package-config
Description: Löscht eine Paket-Konfiguration der Organisation. Das ist nur möglich, wenn keine Kunden aktuell diesen :packageType verwenden. Das Paket wird direkt über den Pfad-Parameter aufgelöst. Werte wie test1 funktionieren also, solange sie exakt dem gespeicherten packageType entsprechen.
Summary: `DELETE /api/package-configs/:packageType` ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X DELETE "$BASE_URL/api/package-configs/pro" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` Hinweise: - Die Organisation wird automatisch aus deiner authentifizierten Session bzw. deinem API-Token abgeleitet. - Die Legacy-Route `DELETE /api/organizations/:organizationPublicId/package-configs/:packageType` bleibt aus Kompatibilitätsgründen weiterhin verfügbar. - Der plurale org-lose Alias `DELETE /api/organizations/package-configs/:packageType` wird ebenfalls unterstützt. - Global Admins brauchen für die org-lose Route einen aktiven Organisationskontext in der Session. ## Antwort (Response) ```json { "success": true } ``` ## Häufige Fehler - `404 Package not found` wenn die Konfiguration nicht existiert - `409 Package is still in use by customers` wenn Kunden diesem Paket zugeordnet sind - `400 Package type is required` wenn `:packageType` fehlt - `400 Organization ID is required in the authenticated session` wenn aus Session/Token keine Organisation abgeleitet werden kann - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf die Organisation hast Hinweis zur Berechtigung: - Schreibzugriff ist erforderlich (Org-Admin oder Global-Admin).

### Rechnungs-Details abrufen
URL: https://docs.uptimeify.io/de/api/organization/get-billing-details
Description: Gibt Rechnungsinformationen und Zahlungsmethoden der Organisation aus deiner authentifizierten Session zurück.
Summary: `GET /api/organization/billing` ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/organization/billing" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` Hinweise: - Die Organisation wird automatisch aus deiner authentifizierten Session bzw. deinem API-Token abgeleitet. - Die Legacy-Route `GET /api/organizations/:organizationPublicId/billing` bleibt aus Kompatibilitätsgründen weiterhin verfügbar. - Der plurale org-lose Alias `GET /api/organizations/billing` wird ebenfalls unterstützt. - Global Admins brauchen für die org-lose Route einen aktiven Organisationskontext in der Session. ## Antwort (Response) ```json { "billingEmail": "billing@beispiel.de", "paymentMethod": "mollie" } ``` ## Häufige Fehler - `400 Organization ID is required in the authenticated session` wenn aus Session/Token keine Organisation abgeleitet werden kann - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf die Organisation hast

### Organisations-Details abrufen
URL: https://docs.uptimeify.io/de/api/organization/get-organization-details
Description: Gibt Details der Organisation aus deiner authentifizierten Session zurück.
Summary: `GET /api/organization` ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/organization" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` Hinweise: - Die Organisation wird automatisch aus deiner authentifizierten Session bzw. deinem API-Token abgeleitet. - Die Legacy-Route `GET /api/organizations/:organizationPublicId` bleibt aus Kompatibilitätsgründen weiterhin verfügbar. - Der plurale org-lose Alias `GET /api/organizations` wird ebenfalls unterstützt. - Global Admins brauchen für die org-lose Route einen aktiven Organisationskontext in der Session. ## Antwort (Response) ```json { "id": 1, "name": "Meine Org", "companyName": "Meine Firma GmbH", "street": "Musterstr. 1", "postalCode": "12345", "city": "Berlin", "country": "DE", "vatId": "DE123456789", "billingEmail": "billing@example.com", "createdAt": "2023-01-01T00:00:00.000Z" } ``` ## Häufige Fehler - `400 Organization ID is required in the authenticated session` wenn aus Session/Token keine Organisation abgeleitet werden kann - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf die Organisation hast

### Rechnungen auflisten
URL: https://docs.uptimeify.io/de/api/organization/list-invoices
Description: Listet alle Rechnungen für die Organisation auf.
Summary: `GET /api/mollie/invoices` ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET \ "$BASE_URL/api/mollie/invoices" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` Hinweise: - Die Organisation wird automatisch aus deiner authentifizierten Session bzw. deinem API-Token abgeleitet. - Die Legacy-Route `GET /api/organizations/:organizationPublicId/mollie/invoices` bleibt aus Kompatibilitätsgründen weiterhin verfügbar. - Die `pdfUrl`-Werte in der Response verwenden die org-lose Download-Route `/api/invoices/:invoiceId/pdf`. - Global Admins brauchen für die org-lose Route einen aktiven Organisationskontext in der Session. ## Antwort (Response) ```json { "invoices": [ { "id": "inv_123456", "reference": "RE-2024-001", "status": "paid", "issuedAt": "2024-01-15T10:00:00.000Z", "netAmount": { "value": "29.99", "currency": "EUR" }, "pdfUrl": "/api/invoices/inv_123456/pdf" }, { "id": "inv_123455", "reference": "RE-2023-128", "status": "paid", "issuedAt": "2023-12-15T10:00:00.000Z", "netAmount": { "value": "29.99", "currency": "EUR" }, "pdfUrl": "/api/invoices/inv_123455/pdf" } ] } ``` ## Häufige Fehler - `400 Organization ID is required in the authenticated session` wenn aus Session/Token keine Organisation abgeleitet werden kann - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Not authorized` wenn du keinen Zugriff auf die Organisation hast

### Paket-Konfigurationen auflisten
URL: https://docs.uptimeify.io/de/api/organization/list-package-configs
Description: Gibt alle Paket-Konfigurationen der Organisation aus deiner authentifizierten Session zurück. Jede Konfiguration enthält zusätzlich usedByCustomerCount.
Summary: `GET /api/package-configs` ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/package-configs" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` Hinweise: - Die Organisation wird automatisch aus deiner authentifizierten Session bzw. deinem API-Token abgeleitet. - Die Legacy-Route `GET /api/organizations/:organizationPublicId/package-configs` bleibt aus Kompatibilitätsgründen weiterhin verfügbar. - Global Admins brauchen für die org-lose Route einen aktiven Organisationskontext in der Session. ## Antwort (Response) ```json [ { "id": 10, "packageType": "pro", "maxUrls": 100, "dataRetentionMonths": 12, "checkIntervalMinutes": 1, "checkLocations": 3, "notificationDelayMinutes": 0, "reminderDelayMinutes": 10, "alertConsecutiveChecks": 3, "alertLocationThreshold": "majority", "alertLocationThresholdCount": 2, "alertReminderInterval": 60, "enableSslCheck": true, "enableHttpsCheck": true, "enableStatusCheck": true, "enableSizeCheck": true, "enableResponseTimeCheck": true, "enableKeywordCheck": false, "enableEmailAlerts": true, "enableSmsAlerts": true, "enableWebhookAlerts": true, "enableIntegrationAlerts": true, "enablePostRequestEscalation": false, "enableMaintenanceWindows": true, "enablePdfReports": true, "notes": null, "createdAt": "2026-02-26T12:00:00.000Z", "updatedAt": "2026-02-26T12:00:00.000Z", "usedByCustomerCount": 4 } ] ``` ## Häufige Fehler - `400 Organization ID is required in the authenticated session` wenn aus Session/Token keine Organisation abgeleitet werden kann - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf die Organisation hast

### Bericht erstellen
URL: https://docs.uptimeify.io/de/api/organization/reports/create-report
Description: Erstellt eine organisationsweite Berichtskonfiguration. Erfordert einen Tarif mit Organisationsberichten und freies Berichtskontingent.
Summary: `POST /api/organization/reports` Erstellt einen wiederkehrenden Organisationsbericht. Die Organisation wird aus Ihrer authentifizierten Sitzung oder Ihrem API-Token abgeleitet. Erfordert die Rolle **admin** der Organisation (API-Tokens gelten als Organisations-Admins). Nur-Lese-Benutzer können keine Berichte erstellen. ## Request-Body | Feld | Typ | Erforderlich | Hinweise | |---|---|---|---| | `name` | string | ja | 1–200 Zeichen. | | `enabled` | boolean | nein | Standard `true`. | | `frequency` | `"daily" \| "weekly" \| "monthly"` | nein | Standard `monthly`. | | `weekday` | integer 0–6 | bei `weekly` | 0 = Sonntag. | | `dayOfMonth` | integer 1–28 | bei `monthly` | Auf 28 begrenzt. | | `sendHour` | integer 0–23 | nein | Standard `2`, in `timezone`. | | `timezone` | string | nein | IANA-Zeitzone, Standard `Europe/Berlin`. | | `scopeMode` | `"all" \| "customers" \| "tags"` | nein | Standard `all`. | | `scopeCustomerIds` | integer[] | bei `customers` | Müssen zu Ihrer Organisation gehören. | | `scopeTagIds` | integer[] | bei `tags` | Müssen zu Ihrer Organisation gehören. | | `inclusionMode` | `"all" \| "problems" \| "threshold"` | nein | Standard `all`. | | `problemSignals` | object | nein | `{ incident, downtimeMinutes, sslDaysLt, responseBreach }`. | | `thresholdUptimeLt` | number | bei `threshold` | z. B. `99.9`. | | `thresholdResponseGt` | integer (ms) | bei `threshold` | | | `sendWhenEmpty` | boolean | nein | „Alles in Ordnung"-Bericht senden, wenn keine Website zutrifft. Standard `false`. | | `sections` | object | nein | Sechs Booleans zum Ein-/Ausschalten der Abschnitte. | | `format` | `"email" \| "email_pdf"` | nein | Standard `email_pdf`. | | `recipientEmails` | string[] | nein | Empfänger auf Agenturseite (max. 50). | | `recipientUserIds` | string[] | nein | Benutzer-IDs der Teammitglieder (max. 50). | ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<ihr-api-token>" curl -X POST "$BASE_URL/api/organization/reports" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "name": "Wöchentlicher Ops-Bericht", "frequency": "weekly", "weekday": 1, "scopeMode": "all", "inclusionMode": "problems", "format": "email_pdf", "recipientEmails": ["ops@agentur.io"] }' ``` ## Antwort ```json { "id": "3f1c9c1e-8d2a-4c7e-9b1a-2d5f6a7b8c90", "name": "Wöchentlicher Ops-Bericht", "enabled": true, "frequency": "weekly", "format": "email_pdf", "recipientEmails": ["ops@agentur.io"] } ``` ## Häufige Fehler - `401 Unauthorized` — nicht authentifiziert. - `403 Forbidden` (`forbidden`) — kein Organisations-Admin. - `400` (`invalidReportSchedule`) — `weekly` ohne `weekday` oder `monthly` ohne `dayOfMonth`. - `400` (`invalidReportScope`) — Scope-IDs gehören nicht zu Ihrer Organisation, oder `threshold` ohne Schwellenwert.

### Bericht löschen
URL: https://docs.uptimeify.io/de/api/organization/reports/delete-report
Description: Löscht eine Berichtskonfiguration der Organisation samt Zeitplan endgültig. Vergangene Bericht-Läufe werden nicht gelöscht.
Summary: `DELETE /api/organization/reports/:id` Löscht eine Berichtskonfiguration. `:id` ist die `id` des Berichts (eine UUID). Die Organisation wird aus Ihrer authentifizierten Sitzung oder Ihrem API-Token abgeleitet, und der Bericht muss zu ihr gehören. Erfordert die Rolle **admin** der Organisation (API-Tokens gelten als Organisations-Admins). Nur-Lese-Benutzer können keine Berichte löschen. Dadurch werden künftige geplante Läufe des Berichts gestoppt. Bereits erzeugte [Bericht-Läufe](/de/api/organization/reports/list-report-runs) für diesen Bericht bleiben davon unberührt und weiterhin abrufbar. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<ihr-api-token>" REPORT_ID="3f1c9c1e-8d2a-4c7e-9b1a-2d5f6a7b8c90" curl -X DELETE "$BASE_URL/api/organization/reports/$REPORT_ID" \ -H "Authorization: Bearer $TOKEN" ``` ## Antwort ```json { "success": true } ``` ## Häufige Fehler - `401 Unauthorized` — nicht authentifiziert. - `403 Forbidden` (`forbidden`) — kein Organisations-Admin. - `404 Not Found` (`notFound`) — es existiert kein Bericht mit dieser ID für Ihre Organisation.

### Bericht-PDF herunterladen
URL: https://docs.uptimeify.io/de/api/organization/reports/download-report-pdf
Description: Leitet auf eine kurzlebige, signierte URL für das archivierte PDF eines Bericht-Laufs weiter.
Summary: `GET /api/organization/report-runs/:id/pdf` Leitet (`302`) auf eine zeitlich begrenzte, signierte Object-Storage-URL für das PDF weiter, das für einen Bericht-Lauf archiviert wurde. `:id` ist die `id` des Laufs (eine UUID), wie sie von [Bericht-Läufe auflisten](/de/api/organization/reports/list-report-runs) zurückgegeben wird. Der Lauf muss zu Ihrer Organisation gehören. Verfügbar für jede Organisationsrolle, auch für **Nur-Lese**-Benutzer. Nur erfolgreich abgeschlossene Läufe mit `format: "email_pdf"` archivieren ein PDF — prüfen Sie `hasPdf` beim Lauf, bevor Sie diesen Endpoint aufrufen. Läufe mit `format: "email"` sowie fehlgeschlagene oder übersprungene Läufe haben kein PDF und liefern `404`. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<ihr-api-token>" RUN_ID="9a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d" curl -X GET "$BASE_URL/api/organization/report-runs/$RUN_ID/pdf" \ -H "Authorization: Bearer $TOKEN" \ -L -o bericht.pdf ``` ## Antwort `302 Found` mit einem `Location`-Header, der auf eine signierte, kurzlebige URL für das PDF-Objekt zeigt. Kein Response-Body. Folgen Sie der Weiterleitung (`-L` bei cURL, oder die Standard-Redirect-Behandlung Ihres HTTP-Clients), um die Datei herunterzuladen. ## Häufige Fehler - `401 Unauthorized` — nicht authentifiziert. - `403 Forbidden` (`forbidden`) — kein Zugriff auf diese Organisation. - `404 Not Found` (`reportRunNotFound`) — es existiert kein Lauf mit dieser ID für Ihre Organisation. - `404 Not Found` (`reportRunNoPdf`) — der Lauf hat kein archiviertes PDF (Nur-E-Mail-Bericht, oder die Erzeugung ist fehlgeschlagen bzw. wurde übersprungen).

### Bericht abrufen
URL: https://docs.uptimeify.io/de/api/organization/reports/get-report
Description: Gibt eine einzelne Berichtskonfiguration der Organisation anhand ihrer Public ID zurück.
Summary: `GET /api/organization/reports/:id` Gibt eine einzelne Berichtskonfiguration zurück. `:id` ist die `id` des Berichts (eine UUID), wie sie von [Bericht erstellen](/de/api/organization/reports/create-report) oder [Berichte auflisten](/de/api/organization/reports/list-reports) zurückgegeben wird. Der Bericht muss zu Ihrer Organisation gehören. Verfügbar für jede Organisationsrolle, auch für **Nur-Lese**-Benutzer. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<ihr-api-token>" REPORT_ID="3f1c9c1e-8d2a-4c7e-9b1a-2d5f6a7b8c90" curl -X GET "$BASE_URL/api/organization/reports/$REPORT_ID" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Antwort ```json { "id": "3f1c9c1e-8d2a-4c7e-9b1a-2d5f6a7b8c90", "name": "Wöchentlicher Ops-Bericht", "enabled": true, "frequency": "weekly", "weekday": 1, "dayOfMonth": null, "sendHour": 2, "timezone": "Europe/Berlin", "scopeMode": "all", "scopeCustomerIds": [], "scopeTagIds": [], "inclusionMode": "problems", "problemSignals": { "incident": true, "downtimeMinutes": 5, "sslDaysLt": 14, "responseBreach": true }, "thresholdUptimeLt": null, "thresholdResponseGt": null, "sendWhenEmpty": false, "sections": { "fleetSummary": true, "worstPerformers": true, "perSiteTable": true, "incidentLog": true, "sslExpiry": true, "groupByCustomer": false }, "format": "email_pdf", "recipientEmails": ["ops@agentur.io"], "recipientUserIds": [], "createdAt": "2026-06-01T02:00:00.000Z", "updatedAt": "2026-06-01T02:00:00.000Z" } ``` ## Häufige Fehler - `401 Unauthorized` — nicht authentifiziert. - `403 Forbidden` (`forbidden`) — kein Zugriff auf diese Organisation. - `404 Not Found` (`notFound`) — es existiert kein Bericht mit dieser ID für Ihre Organisation.

### Bericht-Läufe auflisten
URL: https://docs.uptimeify.io/de/api/organization/reports/list-report-runs
Description: Gibt die Erzeugungs-/Zustellhistorie der Organisationsberichte zurück, optional gefiltert auf einen einzelnen Bericht.
Summary: `GET /api/organization/report-runs` Listet Bericht-Läufe der Organisation, neueste zuerst. Ein Lauf wird bei jeder Erzeugung eines Berichts angelegt — geplant oder über [Bericht sofort senden](/de/api/organization/reports/send-report-now). Die Organisation wird aus Ihrer authentifizierten Sitzung oder Ihrem API-Token abgeleitet. Verfügbar für jede Organisationsrolle, auch für **Nur-Lese**-Benutzer. ## Query-Parameter | Feld | Typ | Erforderlich | Hinweise | |---|---|---|---| | `reportId` | string (uuid) | nein | Beschränkt auf Läufe eines Berichts. Löst sich die ID nicht auf einen Bericht Ihrer Organisation auf, wird `[]` zurückgegeben. | | `limit` | integer | nein | Standard `50`, begrenzt auf `200`. | | `offset` | integer | nein | Standard `0`. | ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<ihr-api-token>" curl -X GET "$BASE_URL/api/organization/report-runs?reportId=3f1c9c1e-8d2a-4c7e-9b1a-2d5f6a7b8c90&limit=20" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Antwort ```json [ { "id": "9a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d", "reportId": "3f1c9c1e-8d2a-4c7e-9b1a-2d5f6a7b8c90", "reportName": "Wöchentlicher Ops-Bericht", "periodStart": "2026-05-25T00:00:00.000Z", "periodEnd": "2026-06-01T00:00:00.000Z", "periodLabel": "25. Mai – 1. Juni 2026", "status": "sent", "trigger": "schedule", "sentAt": "2026-06-01T02:00:12.000Z", "recipients": ["ops@agentur.io"], "hasPdf": true, "summary": { "sitesIncluded": 42, "incidents": 3 }, "createdAt": "2026-06-01T02:00:00.000Z" } ] ``` `status` ist einer von `pending`, `generating`, `sent`, `failed`, `skipped_empty`. `trigger` ist `schedule` oder `manual`. `hasPdf` ist nur `true`, wenn für diesen Lauf ein PDF archiviert wurde — nutzen Sie es, um zu entscheiden, ob [Bericht-PDF herunterladen](/de/api/organization/reports/download-report-pdf) aufgerufen werden soll. ## Häufige Fehler - `401 Unauthorized` — nicht authentifiziert. - `403 Forbidden` (`forbidden`) — kein Zugriff auf diese Organisation.

### Berichte auflisten
URL: https://docs.uptimeify.io/de/api/organization/reports/list-reports
Description: Gibt alle Berichtskonfigurationen der Organisation sowie deren Berichts-Kontingent (Tarif-Feature-Flag und Limit) zurück.
Summary: `GET /api/organization/reports` Listet die wiederkehrenden Berichtskonfigurationen der Organisation, neueste zuerst. Die Organisation wird aus Ihrer authentifizierten Sitzung oder Ihrem API-Token abgeleitet. Verfügbar für jede Organisationsrolle, auch für **Nur-Lese**-Benutzer. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<ihr-api-token>" curl -X GET "$BASE_URL/api/organization/reports" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Antwort ```json { "entitlement": { "enabled": true, "limit": 10 }, "reports": [ { "id": "3f1c9c1e-8d2a-4c7e-9b1a-2d5f6a7b8c90", "name": "Wöchentlicher Ops-Bericht", "enabled": true, "frequency": "weekly", "weekday": 1, "dayOfMonth": null, "sendHour": 2, "timezone": "Europe/Berlin", "scopeMode": "all", "scopeCustomerIds": [], "scopeTagIds": [], "inclusionMode": "problems", "problemSignals": { "incident": true, "downtimeMinutes": 5, "sslDaysLt": 14, "responseBreach": true }, "thresholdUptimeLt": null, "thresholdResponseGt": null, "sendWhenEmpty": false, "sections": { "fleetSummary": true, "worstPerformers": true, "perSiteTable": true, "incidentLog": true, "sslExpiry": true, "groupByCustomer": false }, "format": "email_pdf", "recipientEmails": ["ops@agentur.io"], "recipientUserIds": [], "createdAt": "2026-06-01T02:00:00.000Z", "updatedAt": "2026-06-01T02:00:00.000Z" } ] } ``` `entitlement.enabled` zeigt an, ob der Tarif der Organisation Organisationsberichte enthält; `entitlement.limit` ist die maximale Anzahl an Berichtskonfigurationen. Beide Werte ergeben sich aus den aktiven Pricing-/Custom-Pricing-Datensätzen der Organisation, unabhängig davon, wie viele Berichte aktuell existieren. ## Häufige Fehler - `401 Unauthorized` — nicht authentifiziert. - `403 Forbidden` (`forbidden`) — kein Zugriff auf diese Organisation.

### Bericht sofort senden
URL: https://docs.uptimeify.io/de/api/organization/reports/send-report-now
Description: Stellt eine sofortige, außerplanmäßige Erzeugung und Zustellung eines Organisationsberichts in die Warteschlange.
Summary: `POST /api/organization/reports/:id/send-now` Stellt einen manuellen Lauf einer Berichtskonfiguration in die Warteschlange, unabhängig von deren `frequency`/`sendHour`-Zeitplan. `:id` ist die `id` des Berichts (eine UUID). Die Organisation wird aus Ihrer authentifizierten Sitzung oder Ihrem API-Token abgeleitet, und der Bericht muss zu ihr gehören. Erfordert die Rolle **admin** der Organisation (API-Tokens gelten als Organisations-Admins). Nur-Lese-Benutzer können keinen Versand auslösen. Dieser Endpoint stellt den Job nur in die Warteschlange — er wartet nicht auf Erzeugung oder Zustellung. Fragen Sie [Bericht-Läufe auflisten](/de/api/organization/reports/list-report-runs) (gefiltert nach `reportId`) ab, um den resultierenden Lauf zu sehen, sobald dessen `status` über `pending` hinausgeht. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<ihr-api-token>" REPORT_ID="3f1c9c1e-8d2a-4c7e-9b1a-2d5f6a7b8c90" curl -X POST "$BASE_URL/api/organization/reports/$REPORT_ID/send-now" \ -H "Authorization: Bearer $TOKEN" ``` ## Antwort ```json { "queued": true, "jobId": "orgreport-manual-3f1c9c1e-8d2a-4c7e-9b1a-2d5f6a7b8c90-1b6e..." } ``` ## Häufige Fehler - `401 Unauthorized` — nicht authentifiziert. - `403 Forbidden` (`forbidden`) — kein Organisations-Admin. - `404 Not Found` (`notFound`) — es existiert kein Bericht mit dieser ID für Ihre Organisation.

### Bericht aktualisieren
URL: https://docs.uptimeify.io/de/api/organization/reports/update-report
Description: Aktualisiert eine Berichtskonfiguration der Organisation. Alle Felder sind optional; mindestens eines muss angegeben werden.
Summary: `PATCH /api/organization/reports/:id` Aktualisiert eine Berichtskonfiguration teilweise. `:id` ist die `id` des Berichts (eine UUID). Die Organisation wird aus Ihrer authentifizierten Sitzung oder Ihrem API-Token abgeleitet, und der Bericht muss zu ihr gehören. Erfordert die Rolle **admin** der Organisation (API-Tokens gelten als Organisations-Admins). Nur-Lese-Benutzer können keine Berichte aktualisieren. Senden Sie nur die Felder, die Sie ändern möchten. Die feldübergreifende Validierung (Zeitplan und Scope) wird gegen das **zusammengeführte** Ergebnis erneut ausgeführt — ein `PATCH`, der nur `frequency` auf `weekly` setzt, ohne auch `weekday` mitzusenden, schlägt fehl, wenn der bestehende Bericht kein `weekday` gesetzt hat. ## Request-Body Dieselben Felder wie bei [Bericht erstellen](/de/api/organization/reports/create-report), alle optional — mindestens ein Feld muss aber vorhanden sein: | Feld | Typ | Hinweise | |---|---|---| | `name` | string | 1–200 Zeichen. | | `enabled` | boolean | | | `frequency` | `"daily" \| "weekly" \| "monthly"` | | | `weekday` | integer 0–6 \| null | Praktisch erforderlich, wenn die resultierende `frequency` `weekly` ist. | | `dayOfMonth` | integer 1–28 \| null | Praktisch erforderlich, wenn die resultierende `frequency` `monthly` ist. | | `sendHour` | integer 0–23 | | | `timezone` | string | IANA-Zeitzone. | | `scopeMode` | `"all" \| "customers" \| "tags"` | | | `scopeCustomerIds` | integer[] | Müssen zu Ihrer Organisation gehören. | | `scopeTagIds` | integer[] | Müssen zu Ihrer Organisation gehören. | | `inclusionMode` | `"all" \| "problems" \| "threshold"` | | | `problemSignals` | object | `{ incident, downtimeMinutes, sslDaysLt, responseBreach }`. | | `thresholdUptimeLt` | number \| null | | | `thresholdResponseGt` | integer (ms) \| null | | | `sendWhenEmpty` | boolean | | | `sections` | object | Sechs Booleans zum Ein-/Ausschalten der Abschnitte. | | `format` | `"email" \| "email_pdf"` | | | `recipientEmails` | string[] | Max. 50. | | `recipientUserIds` | string[] | Max. 50. | ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<ihr-api-token>" REPORT_ID="3f1c9c1e-8d2a-4c7e-9b1a-2d5f6a7b8c90" curl -X PATCH "$BASE_URL/api/organization/reports/$REPORT_ID" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "enabled": false, "recipientEmails": ["ops@agentur.io", "cs@agentur.io"] }' ``` ## Antwort ```json { "id": "3f1c9c1e-8d2a-4c7e-9b1a-2d5f6a7b8c90", "name": "Wöchentlicher Ops-Bericht", "enabled": false, "frequency": "weekly", "weekday": 1, "dayOfMonth": null, "sendHour": 2, "timezone": "Europe/Berlin", "scopeMode": "all", "inclusionMode": "problems", "format": "email_pdf", "recipientEmails": ["ops@agentur.io", "cs@agentur.io"], "recipientUserIds": [] } ``` ## Häufige Fehler - `401 Unauthorized` — nicht authentifiziert. - `403 Forbidden` (`forbidden`) — kein Organisations-Admin. - `404 Not Found` (`notFound`) — es existiert kein Bericht mit dieser ID für Ihre Organisation. - `400` (`invalidReportSchedule`) — die resultierende `weekly`-Konfiguration hat kein `weekday`, oder die resultierende `monthly`-Konfiguration hat kein `dayOfMonth`. - `400` (`invalidReportScope`) — Scope-IDs gehören nicht zu Ihrer Organisation, oder der resultierende `threshold`-Modus hat keinen Schwellenwert.

### Rechnungs-Details aktualisieren
URL: https://docs.uptimeify.io/de/api/organization/update-billing-details
Description: Aktualisiert Rechnungsinformationen der Organisation aus deiner authentifizierten Session.
Summary: `PATCH /api/organization/billing` ## Anfrage (Request Body) ```json { "billingEmail": "billing@example.com" } ``` ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X PATCH "$BASE_URL/api/organization/billing" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -H "Accept: application/json" \ -d '{ "billingEmail": "billing@example.com" }' ``` ## Hinweise - Dieses Endpoint akzeptiert aktuell nur `billingEmail`. - Die Organisation wird automatisch aus deiner authentifizierten Session bzw. deinem API-Token abgeleitet. - Die Legacy-Route `PATCH /api/organizations/:organizationPublicId/billing` bleibt aus Kompatibilitätsgründen weiterhin verfügbar. - Der plurale org-lose Alias `PATCH /api/organizations/billing` wird ebenfalls unterstützt. - Global Admins brauchen für die org-lose Route einen aktiven Organisationskontext in der Session. ## Häufige Fehler - `400 Invalid request body` wenn der Payload nicht zum Schema passt - `400 Organization ID is required in the authenticated session` wenn aus Session/Token keine Organisation abgeleitet werden kann - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keine Admin-Berechtigung zum Aktualisieren der Rechnungsinformationen hast ## Antwort (Response) Gibt die aktualisierten Rechnungsdetails zurück. Siehe [Fehlerliste](/de/api/error-codes-and-known-pitfalls) für Fehlerantworten.

### Organisation aktualisieren
URL: https://docs.uptimeify.io/de/api/organization/update-organization
Description: Aktualisiert die Organisation aus deiner authentifizierten Session.
Summary: `PATCH /api/organization` ## Anfrage (Request Body) ```json { "name": "Neuer Name", "companyName": "Neuer Firmenname", "street": "Neue Straße", "postalCode": "54321", "city": "Neue Stadt", "country": "US", "vatId": "US123", "billingEmail": "neu@example.com", "defaultNotificationChannels": { "email": true, "sms": false, "webhook": true, "integrations": false }, "defaultNotificationTargets": { "email": "both", // customer, organization, both "sms": "organization", "webhook": "organization", "integrations": "customer" } } ``` ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X PATCH "$BASE_URL/api/organization" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -H "Accept: application/json" \ -d '{ "name": "Neuer Name", "billingEmail": "neu@example.com" }' ``` Hinweise: - Die Organisation wird automatisch aus deiner authentifizierten Session bzw. deinem API-Token abgeleitet. - Die Legacy-Route `PATCH /api/organizations/:organizationPublicId` bleibt aus Kompatibilitätsgründen weiterhin verfügbar. - Der plurale org-lose Alias `PATCH /api/organizations` wird ebenfalls unterstützt. - Global Admins brauchen für die org-lose Route einen aktiven Organisationskontext in der Session. ## Häufige Fehler - `400 Invalid request body` wenn der Payload nicht zum Schema passt - `400 Organization ID is required in the authenticated session` wenn aus Session/Token keine Organisation abgeleitet werden kann - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keine Admin-Berechtigung zum Aktualisieren der Organisation hast ## Antwort (Response) Gibt das aktualisierte Organisationsobjekt zurück. Siehe [Fehlerliste](/de/api/error-codes-and-known-pitfalls) für Fehlerantworten.

### Paket-Konfiguration erstellen/aktualisieren
URL: https://docs.uptimeify.io/de/api/organization/upsert-package-config
Description: Erstellt eine neue Paket-Konfiguration (über :packageType) oder aktualisiert eine bestehende. packageType ist ein frei wählbarer Bezeichner der Organisation. Customer-Endpoints können später genau diesen Key verwenden.
Summary: `PATCH /api/package-configs/:packageType` Hier werden u.a. Alerting-Defaults wie `alertConsecutiveChecks` sowie Feature-Flags wie `enableEmailAlerts` gepflegt. ## Anfrage (Request Body) Alle Felder sind optional. Wenn du im UI einen lesbaren Namen anzeigen willst, kannst du zusätzlich `displayName` setzen und den technischen `packageType` stabil halten. ```json { "displayName": "Pro Care", "maxUrls": 100, "dataRetentionMonths": 12, "checkIntervalMinutes": 1, "checkLocations": 3, "notificationDelayMinutes": 0, "reminderDelayMinutes": 10, "alertConsecutiveChecks": 3, "alertLocationThreshold": "majority", "alertLocationThresholdCount": 2, "alertReminderInterval": 60, "enableEmailAlerts": true, "enableSmsAlerts": true, "enableWebhookAlerts": true, "enableIntegrationAlerts": true, "enablePostRequestEscalation": false, "enableMaintenanceWindows": true, "enablePdfReports": true, "allowSelfService": true, "maxSelfServiceUrls": 10, "notes": "Default für PRO-Kunden" } ``` ### Monitor-Ownership-Standards `allowSelfService` (Standard `false`) und `maxSelfServiceUrls` (Standard `0`) sind die Paket-Standards für das [Managed-vs.-Self-Service](/de/monitoring/managed-vs-self-service)-Modell. Jeder Kunde des Pakets erbt sie, sofern der Kunde keinen eigenen non-`null`-Override trägt (siehe [Kunden aktualisieren](/de/api/customers/update-customer)). `maxSelfServiceUrls` begrenzt die **Gesamtzahl** der Self-Service-Monitore eines Kunden über alle Monitor-Typen. Die `enable*`-Alarm-Flags fungieren zugleich als vererbte Kanal-Typ-Policy desselben Modells. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X PATCH "$BASE_URL/api/package-configs/pro" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -H "Accept: application/json" \ -d '{ "displayName":"Pro Care", "maxUrls":100, "dataRetentionMonths":12, "checkIntervalMinutes":1, "checkLocations":3, "notificationDelayMinutes":0, "reminderDelayMinutes":10, "alertConsecutiveChecks":3, "alertLocationThreshold":"majority", "alertLocationThresholdCount":2, "alertReminderInterval":60, "enableEmailAlerts":true, "enableSmsAlerts":true, "enableWebhookAlerts":true, "enableIntegrationAlerts":true, "enableMaintenanceWindows":true, "enablePdfReports":true, "notes":"Default für PRO-Kunden" }' ``` ## Antwort (Response) Gibt die erstellte/aktualisierte Paket-Konfiguration zurück. ```json { "id": 10, "packageType": "pro", "displayName": "Pro Care", "maxUrls": 100, "dataRetentionMonths": 12, "checkIntervalMinutes": 1, "checkLocations": 3, "notificationDelayMinutes": 0, "reminderDelayMinutes": 10, "alertConsecutiveChecks": 3, "alertLocationThreshold": "majority", "alertLocationThresholdCount": 2, "alertReminderInterval": 60, "enableEmailAlerts": true, "enableSmsAlerts": true, "enableWebhookAlerts": true, "enableIntegrationAlerts": true, "enableMaintenanceWindows": true, "enablePdfReports": true, "notes": "Default für PRO-Kunden", "createdAt": "2026-02-26T12:00:00.000Z", "updatedAt": "2026-02-26T12:00:00.000Z" } ``` Hinweise: - Die Organisation wird automatisch aus deiner authentifizierten Session bzw. deinem API-Token abgeleitet. - Die body-basierte Variante `PATCH /api/package-configs` wird ebenfalls unterstützt, wenn `packageType` im Request-Body mitgesendet wird. - Die Legacy-Route `PATCH /api/organizations/:organizationPublicId/package-configs/:packageType` bleibt aus Kompatibilitätsgründen weiterhin verfügbar. - Der plurale org-lose Alias `PATCH /api/organizations/package-configs/:packageType` wird ebenfalls unterstützt. - Global Admins brauchen für die org-lose Route einen aktiven Organisationskontext in der Session. ## Häufige Fehler - `400 Package type is required` wenn `:packageType` fehlt - `400 Organization ID is required in the authenticated session` wenn aus Session/Token keine Organisation abgeleitet werden kann - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf die Organisation hast Hinweis zur Ber…

### Status-Seiten
URL: https://docs.uptimeify.io/de/api/status-pages
Description: Status-Seiten ermöglichen es, den Betriebsstatus überwachter Dienste für Kunden oder die Öffentlichkeit transparent darzustellen.
Summary: Sie können öffentlich zugänglich oder auf Kundenmitglieder beschränkt sein. Eigene Domains werden per DNS-Verifizierung eingebunden. ## Authentifizierung Alle Beispiele setzen einen Bearer-Token voraus: ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" ``` ## Endpunkte - [Status-Seiten auflisten](./status-seiten-auflisten) - [Status-Seite erstellen](./status-seite-erstellen) - [Status-Seite abfragen](./status-seite-abfragen) - [Status-Seite aktualisieren](./status-seite-aktualisieren) - [Status-Seite löschen](./status-seite-loeschen) - [Öffentliche Status-Seite abfragen](./oeffentliche-status-seite-abfragen) - [Design abfragen](./design-abfragen) - [Design aktualisieren](./design-aktualisieren) - [Eigene Domain hinzufügen](./domain-hinzufuegen) - [Eigene Domain entfernen](./domain-entfernen) - [Status-Seiten-Domain verifizieren](./domain-verifizieren) - [Status-Seiten-Domain aktivieren](./domain-aktivieren)

### Status-Seiten-Domain aktivieren
URL: https://docs.uptimeify.io/de/api/status-pages/activate-status-page-domain
Description: Aktiviert eine verifizierte eigene Domain für eine Status-Seite. Nur Admin.
Summary: `POST /api/status-pages/domains/activate` ## Request-Body | Feld | Typ | Pflicht | Standard | Beschreibung | |------|-----|---------|----------|--------------| | `domainId` | number | Ja | — | Die ID der verifizierten Domain, die aktiviert werden soll | ## Beispiel (cURL) ```bash curl -X POST "$BASE_URL/api/status-pages/domains/activate" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "domainId": 42 }' ``` ## Antwort ```json { "activated": true, "domain": { "id": 42, "hostname": "status.example.com", "status": "active", "role": "status_page", "isPrimary": false, "verificationToken": "abc123-def456-ghi789", "verifiedAt": "2026-05-01T12:00:00.000Z", "createdAt": "2026-05-01T11:00:00.000Z", "updatedAt": "2026-05-01T12:30:00.000Z" } } ``` ## Häufige Fehler - `401 Unauthorized`, wenn nicht authentifiziert - `403 Forbidden`, wenn kein Admin - `400 Bad Request`, wenn die Domain noch nicht verifiziert ist

### Eigene Domain hinzufügen
URL: https://docs.uptimeify.io/de/api/status-pages/add-status-page-domain
Description: Fügt einer bestehenden Status-Seite einen eigenen Hostnamen hinzu und gibt den für die Verifizierung nötigen DNS-TXT-Eintrag zurück. Nur Admin.
Summary: `POST /api/status-pages/domains` ## Request-Body | Feld | Typ | Pflicht | Beschreibung | |------|-----|---------|--------------| | `statusPageId` | number \| string | Ja | Die ID oder publicId der Status-Seite | | `hostname` | string | Ja | Der eigene Hostname (z.B. `status.example.com`) | ## Beispiel (cURL) ```bash curl -X POST "$BASE_URL/api/status-pages/domains" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "statusPageId": 1, "hostname": "status.example.com" }' ``` ## Antwort ```json { "domain": { "id": 42, "hostname": "status.example.com", "status": "pending", "role": "status_page", "verificationToken": "abc123-def456-ghi789", "verifiedAt": null, "createdAt": "2026-05-01T11:00:00.000Z", "updatedAt": "2026-05-01T11:00:00.000Z" }, "dns": { "txtName": "_uptimeify-verify.status.example.com", "txtValue": "abc123-def456-ghi789" } } ``` ## Häufige Fehler - `401 Unauthorized`, wenn nicht authentifiziert - `403 Forbidden`, wenn kein Admin - `404 Not found`, wenn die Status-Seite nicht existiert - `409 Conflict`, wenn der Hostname bereits verwendet wird - `422 Unprocessable Entity`, wenn der Hostname reserviert oder ungültig ist

### Status-Seite erstellen
URL: https://docs.uptimeify.io/de/api/status-pages/create-status-page
Description: Erstellt eine neue Status-Seite. Erfordert Admin-Rolle.
Summary: `POST /api/status-pages` ## Request-Body | Feld | Typ | Pflicht | Standard | Beschreibung | |------|-----|---------|----------|--------------| | `customerId` | number | Ja | — | Kunden-ID (muss zu Ihrer Organisation gehören) | | `name` | string | Ja | — | Anzeigename (1–120 Zeichen). Slug wird aus dem Namen generiert. | | `slug` | string | Nein | auto | URL-Slug (1–120 Zeichen, auto-normalisiert auf Kleinbuchstaben-Bindestriche) | | `description` | string | Nein | null | Beschreibung (max. 1000 Zeichen) | | `visibility` | string | Nein | `public` | `public` oder `customer_members_only` | | `isPublished` | boolean | Nein | true | Ob die Seite öffentlich sichtbar ist | | `customDomainHostname` | string | Nein | null | Eigene Domain (3–253 Zeichen). Erzeugt einen ausstehenden DNS-Verifizierungseintrag. | | `hiddenMonitors` | array | Nein | `[]` | Monitore, die auf dieser Statusseite ausgeblendet werden. Jeder Eintrag ist `{ "type": "http"\|"dns"\|"icmp"\|"smtp"\|"ssh"\|"ftp"\|"imap_pop", "id": <Monitor-ID> }`. Leer lassen oder `[]` senden, um alle Monitore anzuzeigen (Standard). Später hinzugefügte Monitore erscheinen automatisch. Maximal 500 Einträge. | ## Beispiel (cURL) ```bash curl -X POST "$BASE_URL/api/status-pages" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "customerId": 5, "name": "Production Status", "description": "Real-time status of our production services", "visibility": "public", "hiddenMonitors": [{ "type": "http", "id": 42 }] }' ``` ## Antwort ```json { "statusPage": { "id": 1, "publicId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890", "organizationId": 1, "customerId": 5, "name": "Production Status", "slug": "production-status", "description": "Real-time status of our production services", "visibility": "public", "isPublished": true, "showRecentIncidents": false, "showRecentMaintenance": false, "customDomainId": null, "createdAt": "2026-01-15T10:00:00.000Z", "updatedAt": "2026-01-15T10:00:00.000Z" }, "dns": null } ``` Wird `customDomainHostname` angegeben, enthält die Antwort DNS-Verifizierungshinweise: ```json { "dns": { "txtName": "_uptimeify-verify.status.example.com", "txtValue": "abc123-def456-ghi789" } } ``` ## Häufige Fehler - `401 Unauthorized`, wenn nicht authentifiziert - `403 Forbidden`, wenn kein Admin - `409 Conflict`, wenn der Slug bereits vergeben ist

### Status-Seite löschen
URL: https://docs.uptimeify.io/de/api/status-pages/delete-status-page
Description: Löscht eine Status-Seite endgültig. Erfordert Admin-Rolle.
Summary: `DELETE /api/status-pages/:id` ## Beispiel (cURL) ```bash curl -X DELETE "$BASE_URL/api/status-pages/1" \ -H "Authorization: Bearer $TOKEN" ``` ## Antwort ```json { "deleted": true, "id": 1 } ``` ## Häufige Fehler - `401 Unauthorized`, wenn nicht authentifiziert - `403 Forbidden`, wenn kein Admin - `404 Not found`, wenn die Status-Seite nicht existiert

### Öffentliche Status-Seite abfragen
URL: https://docs.uptimeify.io/de/api/status-pages/get-public-status-page
Description: Zwei Endpunkte liefern die öffentliche Status-Seiten-Ansicht:
Summary: - `GET /api/status-pages/public/:slug` — Abruf per URL-Slug - `GET /api/status-pages/public/by-id/:id` — Abruf per numerischer ID Keine Authentifizierung nötig für Seiten mit `visibility: public`. Für Seiten mit `visibility: customer_members_only` ist eine Kundenmitglieds-Authentifizierung erforderlich. ## Antwort ```json { "statusPage": { "id": 1, "organizationId": 1, "customerId": 5, "name": "Production Status", "slug": "production-status", "description": "Real-time status of our production services", "visibility": "public", "isPublished": true, "showRecentIncidents": true, "showRecentMaintenance": true, "overallState": "operational", "createdAt": "2026-01-15T10:00:00.000Z", "updatedAt": "2026-01-15T10:00:00.000Z" }, "websites": [ { "id": 101, "name": "Main Site", "url": "https://example.com", "status": "active", "state": "operational", "inMaintenance": false, "openIncidents": 0, "lastCheckedAt": "2026-05-01T12:00:00.000Z" } ], "maintenanceHistory": [], "incidentHistory": [] } ``` `state`-Werte: `operational`, `warning` (nur SSL-Vorfälle), `degraded` (Nicht-SSL-Vorfälle), `maintenance` (aktives Wartungsfenster). `overallState` ist der schwerwiegendste Status über alle Websites. ## Häufige Fehler - `404 Not found`, wenn die Status-Seite nicht existiert oder nicht veröffentlicht ist - `403 Forbidden` bei `customer_members_only`-Seiten, wenn der Nutzer kein Mitglied ist

### Design abfragen
URL: https://docs.uptimeify.io/de/api/status-pages/get-status-page-design
Description: Gibt die aktuelle visuelle Designkonfiguration einer Status-Seite zurück. Erfordert Admin-Rolle.
Summary: `GET /api/status-pages/:id/design` ## Pfad-Parameter | Parameter | Beschreibung | |-----------|-------------| | `id` | Status-Seiten-ID oder `publicId` (UUID) | ## Beispiel (cURL) ```bash curl "$BASE_URL/api/status-pages/db58058e-4b58-4d97-a314-3bb8e279a182/design" \ -H "Authorization: Bearer $TOKEN" ``` ## Antwort ```json { "designConfig": { "layout": "timeline", "colorScheme": "dark", "accentColor": "#f59e0b", "headerStyle": "simple", "fontFamily": "system", "cardRadius": "md", "pageWidth": "lg", "customTitle": "", "customSubtitle": "", "showPoweredBy": true, "showUptimeStats": true, "showServiceUrls": false, "showLastChecked": false, "showHistory": true } } ``` Wenn noch kein Design gespeichert wurde, werden alle Felder mit den Standardwerten befüllt. ## Fehler - `401 Unauthorized` – nicht angemeldet - `403 Forbidden` – keine Admin-Rechte - `404 Not found` – Status-Seite nicht gefunden

### Status-Seiten auflisten
URL: https://docs.uptimeify.io/de/api/status-pages/list-status-pages
Description: Gibt alle Status-Seiten der Organisation zurück. Jede Seite enthält ihre Custom-Domain-Infos, sofern konfiguriert.
Summary: `GET /api/status-pages` ## Beispiel (cURL) ```bash curl -X GET "$BASE_URL/api/status-pages" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Antwort ```json { "statusPages": [ { "id": 1, "publicId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890", "organizationId": 1, "customerId": 5, "customerPublicId": "f7e6d5c4-b3a2-1098-7654-321fedcba098", "name": "Production Status", "slug": "production-status", "description": "Real-time status of our production services", "visibility": "public", "isPublished": true, "showRecentIncidents": true, "showRecentMaintenance": true, "customDomainId": null, "createdAt": "2026-01-15T10:00:00.000Z", "updatedAt": "2026-01-15T10:00:00.000Z" } ] } ``` ## Häufige Fehler - `401 Unauthorized`, wenn nicht authentifiziert

### Eigene Domain entfernen
URL: https://docs.uptimeify.io/de/api/status-pages/remove-status-page-domain
Description: Entfernt eine eigene Domain von einer Status-Seite. Löscht den Domain-Datensatz; die customDomainId der Status-Seite wird automatisch auf null gesetzt. Nur Admin.
Summary: `DELETE /api/status-pages/domains/:id` ## Pfad-Parameter | Parameter | Typ | Beschreibung | |-----------|-----|--------------| | `id` | number | Die zu entfernende Domain-ID | ## Beispiel (cURL) ```bash curl -X DELETE "$BASE_URL/api/status-pages/domains/42" \ -H "Authorization: Bearer $TOKEN" ``` ## Antwort `204 No Content` ## Häufige Fehler - `401 Unauthorized`, wenn nicht authentifiziert - `403 Forbidden`, wenn kein Admin - `404 Not found`, wenn die Domain nicht existiert - `422 Unprocessable Entity`, wenn die Domain-ID ungültig ist

### Status-Seite aktualisieren
URL: https://docs.uptimeify.io/de/api/status-pages/update-status-page
Description: Aktualisiert eine Status-Seite. Mindestens ein Feld muss angegeben werden. Erfordert Admin-Rolle.
Summary: `PATCH /api/status-pages/:id` ## Request-Body (alle optional) | Feld | Typ | Beschreibung | |------|-----|--------------| | `customerId` | number | Status-Seite zu einem anderen Kunden verschieben | | `name` | string | Anzeigename (1–120 Zeichen) | | `slug` | string | URL-Slug (1–120 Zeichen, 409 bei Konflikt) | | `description` | string\|null | Beschreibung (max. 1000 Zeichen). `null` löscht sie. | | `visibility` | string | `public` oder `customer_members_only` | | `isPublished` | boolean | Seite veröffentlichen oder verbergen | | `showRecentIncidents` | boolean | Abschnitt „Letzte Vorfälle" anzeigen | | `showRecentMaintenance` | boolean | Abschnitt „Letzte Wartungen" anzeigen | | `designConfig` | object | Visuelle Design-Einstellungen (Layout, Farben, Typografie, …). Alle Felder siehe [Design aktualisieren](./design-aktualisieren). | | `hiddenMonitors` | array | Monitore, die auf dieser Statusseite ausgeblendet werden. Jeder Eintrag ist `{ "type": "http"\|"dns"\|"icmp"\|"smtp"\|"ssh"\|"ftp"\|"imap_pop", "id": <Monitor-ID> }`. Leer lassen oder `[]` senden, um alle Monitore anzuzeigen (Standard). Später hinzugefügte Monitore erscheinen automatisch. Maximal 500 Einträge. | Wenn angegeben, ersetzt `hiddenMonitors` die gespeicherte Liste vollständig; ohne das Feld bleibt sie unverändert; `[]` zeigt wieder alle Monitore an. ## Beispiel (cURL) ```bash curl -X PATCH "$BASE_URL/api/status-pages/1" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "name": "Production Status - Updated", "isPublished": true, "showRecentIncidents": true, "hiddenMonitors": [{ "type": "http", "id": 42 }] }' ``` ## Häufige Fehler - `401 Unauthorized`, wenn nicht authentifiziert - `403 Forbidden`, wenn kein Admin - `404 Not found`, wenn die Status-Seite nicht existiert - `409 Conflict`, wenn der Slug bereits vergeben ist ## Antwort (Response) Gibt das aktualisierte Status-Seiten-Objekt zurück. Siehe [Fehlerliste](/de/api/error-codes-and-known-pitfalls) für Fehlerantworten.

### Design aktualisieren
URL: https://docs.uptimeify.io/de/api/status-pages/update-status-page-design
Description: Aktualisiert die visuelle Designkonfiguration einer Status-Seite. Es werden nur die übermittelten Felder geändert – alle anderen Einstellungen bleiben unverändert. Erfordert Admin-Rolle.
Summary: `PATCH /api/status-pages/:id/design` ## Pfad-Parameter | Parameter | Beschreibung | |-----------|-------------| | `id` | Status-Seiten-ID oder `publicId` (UUID) | ## Request Body (alle Felder optional) ### Layout | Feld | Typ | Werte | Standard | Beschreibung | |------|-----|-------|----------|-------------| | `layout` | string | `classic` `cards` `minimal` `sleek` `board` `split` `timeline` `compact` | `classic` | Visuelles Layout-Template | | `pageWidth` | string | `sm` `md` `lg` `xl` | `lg` | Maximale Inhaltsbreite: sm = 672 px, md = 896 px, lg = 1024 px, xl = 1280 px | ### Farben | Feld | Typ | Werte | Standard | Beschreibung | |------|-----|-------|----------|-------------| | `colorScheme` | string | `light` `dark` `auto` | `auto` | Farbmodus. `auto` folgt der Systemeinstellung des Besuchers. | | `accentColor` | string | Hex, z. B. `#6366f1` | `#6366f1` | Akzentfarbe für Highlights, Rahmen und Verläufe | ### Typografie & Stil | Feld | Typ | Werte | Standard | Beschreibung | |------|-----|-------|----------|-------------| | `fontFamily` | string | `system` `mono` | `system` | `system` = Standard-Serifenloser, `mono` = Monospace | | `cardRadius` | string | `none` `md` `xl` | `md` | Abrundung der Karten: none = eckig, md = abgerundet, xl = stark abgerundet | ### Header | Feld | Typ | Werte | Standard | Beschreibung | |------|-----|-------|----------|-------------| | `headerStyle` | string | `simple` `centered` `hero` | `simple` | `simple` = linksbündig, `centered` = zentriert, `hero` = breites Gradient-Banner | | `customTitle` | string | max. 120 Zeichen | `""` | Überschreibt den Seitennamen im Header. Leer lassen, um den Seitennamen zu verwenden. | | `customSubtitle` | string | max. 200 Zeichen | `""` | Optionaler Untertitel unterhalb des Titels | ### Anzeigeoptionen | Feld | Typ | Standard | Beschreibung | |------|-----|----------|-------------| | `showUptimeStats` | boolean | `true` | Verfügbarkeitsprozent und Dienst-Übersicht anzeigen | | `showServiceUrls` | boolean | `false` | Überwachte URL unterhalb des Dienstnamens anzeigen | | `showLastChecked` | boolean | `false` | Zeitstempel der letzten Prüfung je Dienst anzeigen | | `showHistory` | boolean | `true` | Bereich für vergangene Vorfälle & Wartungsfenster anzeigen | | `showPoweredBy` | boolean | `true` | „Powered by …"-Badge im Footer anzeigen | ## Beispiel – Dunkles Timeline-Layout ```bash curl -X PATCH "$BASE_URL/api/status-pages/db58058e-4b58-4d97-a314-3bb8e279a182/design" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "layout": "timeline", "colorScheme": "dark", "accentColor": "#f59e0b", "pageWidth": "lg" }' ``` ## Beispiel – Minimalistisch, kein Branding, volle Breite ```bash curl -X PATCH "$BASE_URL/api/status-pages/db58058e-4b58-4d97-a314-3bb8e279a182/design" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "layout": "minimal", "colorScheme": "light", "pageWidth": "xl", "showPoweredBy": false, "showUptimeStats": false, "customTitle": "System-Status", "customSubtitle": "Live-Übersicht aller Dienste" }' ``` ## Antwort ```json { "designConfig": { "layout": "timeline", "colorScheme": "dark", "accentColor": "#f59e0b", "headerStyle": "simple", "fontFamily": "system", "cardRadius": "md", "pageWidth": "lg", "customTitle": "", "customSubtitle": "", "showPoweredBy": true, "showUptimeStats": true, "showServiceUrls": false, "showLastChecked": false, "showHistory": true } } ``` ## Fehler - `400 Bad Request` – ungültiger Feldwert (z. B. unbekannter Layout-Name oder falsches Hex-Farb-Format) - `401 Unauthorized` – nicht angemeldet - `403 Forbidden` – keine Admin-Rechte - `404 Not found` – Status-Seite nicht gefunden

### Status-Seiten-Domain verifizieren
URL: https://docs.uptimeify.io/de/api/status-pages/verify-status-page-domain
Description: Verifiziert die DNS-TXT-Einträge einer eigenen Status-Seiten-Domain. Nur Admin.
Summary: `POST /api/status-pages/domains/verify` ## Request-Body | Feld | Typ | Pflicht | Beschreibung | |------|-----|---------|--------------| | `domainId` | number | Ja | Die zu verifizierende Domain-ID | ## Beispiel (cURL) ```bash curl -X POST "$BASE_URL/api/status-pages/domains/verify" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "domainId": 42 }' ``` ## Antwort (Erfolg) ```json { "verified": true, "status": "verified", "domain": { "id": 42, "hostname": "status.example.com", "status": "verified", "role": "status_page", "verificationToken": "abc123-def456-ghi789", "verifiedAt": "2026-05-01T12:00:00.000Z", "createdAt": "2026-05-01T11:00:00.000Z", "updatedAt": "2026-05-01T12:00:00.000Z" } } ``` ## Häufige Fehler - `401 Unauthorized`, wenn nicht authentifiziert - `403 Forbidden`, wenn kein Admin - `404 Not found`, wenn die Domain nicht existiert

### Tags
URL: https://docs.uptimeify.io/de/api/tags
Description: Organisiere deine Monitore mit Tags — erstellen, zuweisen, filtern und verwalten über alle Monitor-Typen hinweg.
Summary: Tags ermöglichen es dir, jeden Monitor (Website, DNS, ICMP, SMTP, SSH, FTP, IMAP/POP) mit einem oder mehreren farbigen Tags zu versehen und anschließend beliebige Monitor-Listen nach Tag zu filtern. Tags sind auf die Organisation beschränkt; Readonly-Mitglieder können eigene Tags erstellen und verwenden, sehen und verändern aber keine Tags anderer Nutzer. ## Endpunkte - [Tags auflisten](./list-tags) - [Tag erstellen](./create-tag) - [Tag aktualisieren](./update-tag) - [Tag löschen](./delete-tag) - [Tag einem Monitor zuweisen](./assign-tag) - [Tag von Monitor entfernen](./remove-tag) - [Monitor-Tags auflisten](./list-monitor-tags)

### Tag einem Monitor zuweisen
URL: https://docs.uptimeify.io/de/api/tags/assign-tag
Description: Weist einem Monitor einen bestehenden Tag zu. Der Aufrufer benötigt Lesezugriff auf den Monitor und Sichtbarkeit des Tags. Die Operation ist idempotent.
Summary: `POST /api/monitor-tags` ## Body ```json { "monitorType": "website", "monitorId": 101, "tagId": 1 } ``` - `monitorType` (erforderlich): Typ des Monitors. Eines von: `website` | `dns` | `icmp` | `smtp` | `ssh` | `ftp` | `imap_pop`. - `monitorId` (erforderlich): Numerische ID des Monitors. - `tagId` (erforderlich): Numerische ID des zuzuweisenden Tags. Diese Operation ist **idempotent**: Wird sie erneut aufgerufen, wenn der Tag bereits zugewiesen ist, wird die bestehende Zuweisung ohne Fehler zurückgegeben. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X POST "$BASE_URL/api/monitor-tags" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"monitorType":"website","monitorId":101,"tagId":1}' ``` ## Antwort (Response) ```json { "monitorType": "website", "monitorId": 101, "tagId": 1, "createdAt": "2026-06-29T12:00:00.000Z" } ``` ## Häufige Fehler - `400 Bad Request` wenn `monitorType` kein unterstützter Typ ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Lesezugriff auf den Monitor hast oder den Tag nicht siehst - `404 Not Found` wenn Monitor oder Tag nicht existieren

### Tag erstellen
URL: https://docs.uptimeify.io/de/api/tags/create-tag
Description: Erstellt einen neuen Tag in deiner Organisation. Readonly-Mitglieder können Tags erstellen, die nur für sie selbst sichtbar sind.
Summary: `POST /api/tags` ## Body ```json { "name": "Produktion", "color": "red" } ``` - `name` (erforderlich): Anzeigename des Tags (max. 50 Zeichen). - `color` (erforderlich): Einer der Palette-Schlüssel: `slate` | `red` | `amber` | `green` | `teal` | `blue` | `indigo` | `violet` | `pink` | `gray`. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X POST "$BASE_URL/api/tags" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"name":"Produktion","color":"red"}' ``` ## Antwort (Response) ```json { "id": 1, "publicId": "aaaaaaaa-aaaa-4aaa-8aaa-aaaaaaaaaaaa", "organizationId": 10, "name": "Produktion", "color": "red", "createdBy": 42, "createdAt": "2026-06-29T10:00:00.000Z", "updatedAt": "2026-06-29T10:00:00.000Z" } ``` ## Häufige Fehler - `400 invalidTagColor` wenn `color` kein gültiger Palette-Schlüssel ist - `400 Bad Request` wenn `name` fehlt oder das Zeichenlimit überschreitet - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf die Organisation hast

### Tag löschen
URL: https://docs.uptimeify.io/de/api/tags/delete-tag
Description: Löscht einen Tag und entfernt ihn von allen Monitoren, denen er zugewiesen war. Nur der Ersteller oder ein Admin darf löschen.
Summary: `DELETE /api/tags/{id}` Pfadparameter `{id}` ist die numerische `id` des Tags. Das Löschen eines Tags kaskadiert: Alle Monitor-Tag-Zuweisungen für diesen Tag werden automatisch ebenfalls entfernt. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" TAG_ID=1 curl -X DELETE "$BASE_URL/api/tags/$TAG_ID" \ -H "Authorization: Bearer $TOKEN" ``` ## Antwort (Response) Gibt `204 No Content` bei Erfolg zurück. ## Häufige Fehler - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du nicht der Ersteller des Tags oder ein Admin bist - `404 Not Found` wenn der Tag nicht existiert oder für dich nicht sichtbar ist

### Monitor-Tags auflisten
URL: https://docs.uptimeify.io/de/api/tags/list-monitor-tags
Description: Gibt alle einem bestimmten Monitor zugewiesenen Tags zurück. Readonly-Mitglieder sehen nur ihre eigenen Tags.
Summary: `GET /api/monitor-tags` ## Query Parameter - `monitorType` (erforderlich): Typ des Monitors. Eines von: `website` | `dns` | `icmp` | `smtp` | `ssh` | `ftp` | `imap_pop`. - `monitorId` (erforderlich): Numerische ID des Monitors. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/monitor-tags?monitorType=website&monitorId=101" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Antwort (Response) ```json [ { "id": 1, "publicId": "aaaaaaaa-aaaa-4aaa-8aaa-aaaaaaaaaaaa", "organizationId": 10, "name": "Produktion", "color": "red", "createdBy": 42, "createdAt": "2026-06-01T08:00:00.000Z", "updatedAt": "2026-06-01T08:00:00.000Z" } ] ``` ## Häufige Fehler - `400 Bad Request` wenn `monitorType` oder `monitorId` fehlt oder ungültig ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Lesezugriff auf den Monitor hast - `404 Not Found` wenn der Monitor nicht existiert

### Tags auflisten
URL: https://docs.uptimeify.io/de/api/tags/list-tags
Description: Gibt alle für den Aufrufer sichtbaren Tags zurück. Readonly-Mitglieder sehen nur ihre eigenen Tags.
Summary: `GET /api/tags` ## Query Parameter - `organizationId` (optional): Standard ist deine Session-Organisation. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/tags" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Antwort (Response) ```json [ { "id": 1, "publicId": "aaaaaaaa-aaaa-4aaa-8aaa-aaaaaaaaaaaa", "organizationId": 10, "name": "Produktion", "color": "red", "createdBy": 42, "createdAt": "2026-06-01T08:00:00.000Z", "updatedAt": "2026-06-01T08:00:00.000Z" }, { "id": 2, "publicId": "bbbbbbbb-bbbb-4bbb-8bbb-bbbbbbbbbbbb", "organizationId": 10, "name": "Staging", "color": "amber", "createdBy": 42, "createdAt": "2026-06-10T09:00:00.000Z", "updatedAt": "2026-06-10T09:00:00.000Z" } ] ``` ## Häufige Fehler - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf die Organisation hast

### Tag von Monitor entfernen
URL: https://docs.uptimeify.io/de/api/tags/remove-tag
Description: Entfernt eine Tag-Zuweisung von einem Monitor. Der Aufrufer muss Lesezugriff auf den Monitor haben.
Summary: `DELETE /api/monitor-tags` ## Body ```json { "monitorType": "website", "monitorId": 101, "tagId": 1 } ``` - `monitorType` (erforderlich): Typ des Monitors. Eines von: `website` | `dns` | `icmp` | `smtp` | `ssh` | `ftp` | `imap_pop`. - `monitorId` (erforderlich): Numerische ID des Monitors. - `tagId` (erforderlich): Numerische ID des zu entfernenden Tags. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X DELETE "$BASE_URL/api/monitor-tags" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"monitorType":"website","monitorId":101,"tagId":1}' ``` ## Antwort (Response) Gibt `204 No Content` bei Erfolg zurück. ## Häufige Fehler - `400 Bad Request` wenn `monitorType` kein unterstützter Typ ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Lesezugriff auf den Monitor hast - `404 Not Found` wenn die Zuweisung nicht existiert

### Tag aktualisieren
URL: https://docs.uptimeify.io/de/api/tags/update-tag
Description: Aktualisiert Name oder Farbe eines bestehenden Tags. Nur der Ersteller des Tags oder ein Admin darf ihn verändern.
Summary: `PATCH /api/tags/{id}` Pfadparameter `{id}` ist die numerische `id` des Tags. ## Body Alle Felder sind optional; sende nur die Felder, die du ändern möchtest. ```json { "name": "Kritisch", "color": "violet" } ``` - `name` (optional): Neuer Anzeigename (max. 50 Zeichen). - `color` (optional): Einer der Palette-Schlüssel: `slate` | `red` | `amber` | `green` | `teal` | `blue` | `indigo` | `violet` | `pink` | `gray`. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" TAG_ID=1 curl -X PATCH "$BASE_URL/api/tags/$TAG_ID" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"name":"Kritisch","color":"violet"}' ``` ## Antwort (Response) ```json { "id": 1, "publicId": "aaaaaaaa-aaaa-4aaa-8aaa-aaaaaaaaaaaa", "organizationId": 10, "name": "Kritisch", "color": "violet", "createdBy": 42, "createdAt": "2026-06-01T08:00:00.000Z", "updatedAt": "2026-06-29T11:00:00.000Z" } ``` ## Häufige Fehler - `400 invalidTagColor` wenn `color` kein gültiger Palette-Schlüssel ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du nicht der Ersteller des Tags oder ein Admin bist - `404 Not Found` wenn der Tag nicht existiert oder für dich nicht sichtbar ist

### Benutzer
URL: https://docs.uptimeify.io/de/api/users
Description: Verwalte Benutzer innerhalb deiner Organisation.
Summary: ## Endpoints - [Benutzer auflisten](./benutzer-auflisten) - [Benutzer erstellen](./benutzer-erstellen) - [Benutzer abrufen](./benutzer-abrufen) - [Benutzer aktualisieren](./benutzer-aktualisieren) - [Benutzer löschen](./benutzer-loeschen)

### Benutzer erstellen
URL: https://docs.uptimeify.io/de/api/users/create-user
Description: Erstellt einen neuen Benutzer in der Organisation.
Summary: `POST /api/users` ## Anfrage (Request Body) ```json { "email": "jane@example.com", "firstName": "Jane", "lastName": "Doe", "role": "user", // "admin" oder "user" "password": "temporaryPassword123", // Optional, Benutzer kann es später setzen "customerIds": ["11111111-1111-4111-8111-111111111111", "22222222-2222-4222-8222-222222222222"] // Optional: Zugriff auf bestimmte Kunden per Public ID beschränken } ``` Hinweise: - `customerIds` akzeptiert Customer-Public-IDs und weiterhin Legacy-Integer-IDs. - Für neue Integrationen sind Public IDs die bevorzugte Form. ## Antwort (Response) Gibt das erstellte Benutzerobjekt zurück. Siehe [Fehlerliste](/de/api/error-codes-and-known-pitfalls) für Fehlerantworten.

### Benutzer löschen
URL: https://docs.uptimeify.io/de/api/users/delete-user
Description: Entfernt einen Benutzer aus der Organisation.
Summary: `DELETE /api/users/:id` ## Antwort Bei Erfolg: `204 No Content`.

### Benutzer abrufen
URL: https://docs.uptimeify.io/de/api/users/get-user
Description: Gibt die Details eines bestimmten Benutzers zurück.
Summary: `GET /api/users/:id` ## Antwort (Response) ```json { "id": "user_123", "name": "Max Mustermann", "email": "max@example.com", "role": "admin", "isActive": true, "createdAt": "2023-01-01T00:00:00Z" } ```

### Benutzer auflisten
URL: https://docs.uptimeify.io/de/api/users/list-users
Description: Listet alle Benutzer in der Organisation auf.
Summary: `GET /api/users` ## Antwort (Response) ```json { "id": "user_123", "name": "Max Mustermann", "email": "max@example.com", "role": "admin", "isActive": true, "createdAt": "2023-01-01T00:00:00Z" } ```

### Benutzer aktualisieren
URL: https://docs.uptimeify.io/de/api/users/update-user
Description: Aktualisiert die Details und Berechtigungen eines Benutzers.
Summary: `PATCH /api/users/:id` ## Anfrage (Request Body) ```json { "firstName": "Jane", "lastName": "Smith", "role": "admin", "isActive": true, "customerIds": ["11111111-1111-4111-8111-111111111111", "22222222-2222-4222-8222-222222222222"] // Update der Liste zugewiesener Kunden per Public ID } ``` Hinweise: - `customerIds` akzeptiert Customer-Public-IDs und weiterhin Legacy-Integer-IDs. - Für neue Integrationen sind Public IDs die bevorzugte Form. ## Antwort (Response) Gibt das aktualisierte Benutzerobjekt zurück. Siehe [Fehlerliste](/de/api/error-codes-and-known-pitfalls) für Fehlerantworten.

### Konfiguration
URL: https://docs.uptimeify.io/de/api/website-configuration
Description: Verwalte erweiterte Monitoring-Einstellungen für deine Websites.
Summary: ## Authentifizierung Alle Beispiele gehen von einem Bearer-Token aus: ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" ``` ## Check-Konfiguration ### Check-Einstellungen aktualisieren `PATCH /api/websites/:websiteId/check-config` Konfiguriere, welche Aspekte der Website überwacht werden sollen. #### Anfrage (Request Body) ```json { "checkSslEnabled": true, "checkHttpsRedirectEnabled": true, "checkStatusEnabled": true, "checkSizeEnabled": true, "checkResponseTimeEnabled": true, "checkKeywordEnabled": false, "checkDomainExpiryEnabled": true, "minPageSize": 1024, // in Bytes (optional) "maxPageSize": 5242880 // in Bytes (optional) } ``` Beispiel (cURL): ```bash curl -X PATCH \ "$BASE_URL/api/websites/101/check-config" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"checkSslEnabled":true,"checkHttpsRedirectEnabled":true,"checkStatusEnabled":true,"checkSizeEnabled":true,"checkResponseTimeEnabled":true,"checkKeywordEnabled":false,"checkDomainExpiryEnabled":true,"minPageSize":1024,"maxPageSize":5242880}' ``` ## Alarm-Konfigurationen Alarming-Defaults und Feature-Flags werden über **Paket-Konfigurationen der Organisation** verwaltet. Siehe: - [Paket-Konfigurationen auflisten](../organisation/paket-konfigurationen-auflisten) - [Paket-Konfiguration erstellen/aktualisieren](../organisation/paket-konfiguration-upsert) - [Paket-Konfiguration löschen](../organisation/paket-konfiguration-loeschen) ## Benachrichtigungskanäle ## Wartungsfenster ### Wartungsfenster auflisten `GET /api/maintenance-windows?websiteId=:websiteId` ### Wartungsfenster abrufen `GET /api/maintenance-windows/:id` ### Wartungsfenster erstellen `POST /api/maintenance-windows` #### Anfrage (Request Body) ```json { "websiteId": 101, "name": "Server-Upgrade", "description": "Geplante Downtime", "startTime": "2026-02-25T02:00:00.000Z", "endTime": "2026-02-25T04:00:00.000Z", "isRecurring": false, "isActive": true } ``` ### Wartungsfenster aktualisieren `PATCH /api/maintenance-windows/:id` ### Wartungsfenster löschen `DELETE /api/maintenance-windows/:id` ### Wartung prüfen (Website) `GET /api/maintenance-windows/check/:websiteId` ### Wartung prüfen (Batch) `POST /api/maintenance-windows/check/batch` ## Endpunkte - [Check-Einstellungen aktualisieren](./check-konfiguration-aktualisieren) - [Wartungsfenster auflisten](./wartungsfenster-auflisten) - [Wartungsfenster abrufen](./wartungsfenster-abfragen) - [Wartungsfenster erstellen](./wartungsfenster-erstellen) - [Wartungsfenster aktualisieren](./wartungsfenster-aktualisieren) - [Wartungsfenster löschen](./wartungsfenster-loeschen) - [Wartung prüfen (Website)](./wartungsfenster-check-website) - [Wartung prüfen (Batch)](./wartungsfenster-check-website)

### Wartung prüfen (Website)
URL: https://docs.uptimeify.io/de/api/website-configuration/check-maintenance-window
Description: Prüft, ob eine Website aktuell in einem aktiven Wartungsfenster ist.
Summary: `GET /api/maintenance-windows/check/:websiteId` Dieser Endpoint erfordert Authentifizierung per Browser-Session oder API-Token. ## Parameter - `websiteId` (Path, required): Interne numerische Website-ID oder `websitePublicId` (UUID). ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" API_TOKEN="wsm_your_real_api_token" curl -X GET "$BASE_URL/api/maintenance-windows/check/cd11a84d-96a2-41aa-a957-b1db8ee01b72" \ -H "Authorization: Bearer $API_TOKEN" \ -H "Accept: application/json" ``` ## Antwort (Response) ```json { "inMaintenance": true, "activeWindows": [ { "id": 5, "name": "Wöchentliche Wartung", "startTime": "2026-02-25T02:00:00.000Z", "endTime": "2026-02-25T04:00:00.000Z", "description": "Geplante Downtime" } ] } ``` ## Häufige Fehler - `401 Unauthorized` wenn keine gültige Session oder kein gültiger API-Token mitgesendet wird - `403 Forbidden` wenn die Website außerhalb des erlaubten Kunden-/Organisations-Scopes liegt - `400 Invalid Website identifier` wenn `:websiteId` weder eine positive Integer-ID noch eine UUID ist - `404 Website not found` wenn die angegebene `websitePublicId` keiner Website zugeordnet ist

### Wartung prüfen (Batch)
URL: https://docs.uptimeify.io/de/api/website-configuration/check-maintenance-window-batch
Description: Batch-Check für mehrere Websites (reduziert N+1 Requests).
Summary: `POST /api/maintenance-windows/check/batch` Dieser Endpoint erfordert Authentifizierung per Browser-Session oder API-Token. ## Anfrage (Request Body) ```json { "websiteIds": [101, "cd11a84d-96a2-41aa-a957-b1db8ee01b72", 103] } ``` ### Felder - `websiteIds` ((number|string)[], required): numerische Website-IDs oder `websitePublicId`-UUIDs ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" API_TOKEN="wsm_your_real_api_token" curl -X POST "$BASE_URL/api/maintenance-windows/check/batch" \ -H "Authorization: Bearer $API_TOKEN" \ -H "Content-Type: application/json" \ -H "Accept: application/json" \ -d '{"websiteIds":[101,"cd11a84d-96a2-41aa-a957-b1db8ee01b72",103]}' ``` ## Antwort (Response) ```json { "results": { "101": { "inMaintenance": true, "activeWindows": [ { "id": 5, "name": "Wöchentliche Wartung", "startTime": "2026-02-25T02:00:00.000Z", "endTime": "2026-02-25T04:00:00.000Z", "description": "Geplante Downtime" } ] }, "cd11a84d-96a2-41aa-a957-b1db8ee01b72": { "inMaintenance": false, "activeWindows": [] } } } ``` ## Häufige Fehler - `400 websiteIds array required` wenn `websiteIds` fehlt/leer ist - `400 All websiteIds must be valid identifiers` wenn ein Eintrag weder eine positive Integer-ID noch eine UUID ist - `401 Unauthorized` wenn keine gültige Session oder kein gültiger API-Token mitgesendet wird - `403 Forbidden` wenn mindestens eine Website außerhalb des erlaubten Kunden-/Organisations-Scopes liegt - `404 Website not found` wenn eine angegebene `websitePublicId` keiner Website zugeordnet ist

### Wartungsfenster erstellen
URL: https://docs.uptimeify.io/de/api/website-configuration/create-maintenance-window
Description: Erstellt ein neues Wartungsfenster.
Summary: `POST /api/maintenance-windows` Wichtig: Du musst **genau eine** Target-ID angeben (z. B. `websiteId` *oder* `icmpMonitorId`, `smtpMonitorId`, `sshMonitorId`, `ftpMonitorId`, `imapPopMonitorId`). Alle Target-IDs und `customerId` akzeptieren entweder die interne numerische ID oder die jeweilige Public ID als UUID. ## Authentifizierung Erfordert eine gültige Session oder einen gültigen API-Token. - Header: `Authorization: Bearer <token>` Hinweis: Global-Supporter dürfen keine Wartungsfenster erstellen (`403`). Read-only Nutzer dürfen es. ## Anfrage (Request Body) ```json { "websiteId": "521e3338-4597-4d1d-8eeb-dc56d271e71c", "name": "Server-Upgrade", "description": "Geplante Downtime", "startTime": "2026-02-25T02:00:00.000Z", "endTime": "2026-02-25T04:00:00.000Z", "isRecurring": true, "recurrencePattern": { "frequency": "weekly", "interval": 1, "daysOfWeek": [1] }, "isActive": true } ``` ### Felder Ziel (genau eines erforderlich): - `websiteId` (number|string) - `icmpMonitorId` (number|string) - `smtpMonitorId` (number|string) - `sshMonitorId` (number|string) - `ftpMonitorId` (number|string) - `imapPopMonitorId` (number|string) - `customerId` (number|string, optional) Identifier-Regel: Interne numerische IDs oder Public IDs als UUID werden akzeptiert. Weitere Felder: - `name` (string, required) - `description` (string, optional) - Max length: 2000 - Wenn nicht gesetzt (oder leer), wird es als `null` gespeichert. - `startTime` (string/date, required) - `endTime` (string/date, required) - Muss nach `startTime` liegen. - `isRecurring` (boolean, optional) - Default: `false` - `recurrencePattern` (object, optional) - Wird als JSON gespeichert. - Typische Keys: `frequency`, `interval`, `daysOfWeek`, `dayOfMonth`, `endRecurrenceDate`. - `isActive` (boolean, optional) - Default: `true` ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X POST "$BASE_URL/api/maintenance-windows" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"websiteId":"521e3338-4597-4d1d-8eeb-dc56d271e71c","name":"Server-Upgrade","description":"Geplante Downtime","startTime":"2026-02-25T02:00:00.000Z","endTime":"2026-02-25T04:00:00.000Z","isRecurring":true,"recurrencePattern":{"frequency":"weekly","interval":1,"daysOfWeek":[1]},"isActive":true}' ``` ## Antwort (Response) ```json { "id": 5, "websiteId": 101, "icmpMonitorId": null, "smtpMonitorId": null, "sshMonitorId": null, "ftpMonitorId": null, "imapPopMonitorId": null, "customerId": 12, "name": "Server-Upgrade", "description": "Geplante Downtime", "startTime": "2026-02-25T02:00:00.000Z", "endTime": "2026-02-25T04:00:00.000Z", "isRecurring": true, "recurrencePattern": { "frequency": "weekly", "interval": 1, "daysOfWeek": [1] }, "isActive": true, "createdBy": "<user-id>", "createdAt": "2026-02-20T10:00:00.000Z", "updatedAt": "2026-02-20T10:00:00.000Z" } ``` ## Häufige Fehler - `400 Exactly one target ID must be provided` wenn du keine oder mehrere Target-IDs sendest - `400 Invalid Website identifier` bzw. entsprechender Target-Fehler wenn ein Identifier weder Integer-ID noch UUID ist - `400 End time must be after start time` wenn `endTime <= startTime` - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf das Ziel hast (oder global supporter bist)

### Wartungsfenster löschen
URL: https://docs.uptimeify.io/de/api/website-configuration/delete-maintenance-window
Description: Löscht ein Wartungsfenster.
Summary: `DELETE /api/maintenance-windows/:id` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` Hinweis: Global-Supporter dürfen keine Wartungsfenster löschen (`403`). Read-only Nutzer dürfen es. ## Parameter - `id` (Path, required): Wartungsfenster-ID. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X DELETE "$BASE_URL/api/maintenance-windows/5" -H "Authorization: Bearer $TOKEN" ``` ## Antwort (Response) ```json { "success": true } ``` ## Häufige Fehler - `400 Invalid maintenance window ID` wenn `:id` ungültig ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf das Wartungsfenster hast - `404 Maintenance window not found` wenn das Wartungsfenster nicht existiert

### Wartungsfenster abrufen
URL: https://docs.uptimeify.io/de/api/website-configuration/get-maintenance-window
Description: Gibt ein einzelnes Wartungsfenster anhand der ID zurück (inkl. Target-Relation).
Summary: `GET /api/maintenance-windows/:id` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` Hinweis (API-Token Scope): Wenn du ein Customer-scoped API-Token nutzt, muss das Wartungsfenster zu diesem Kunden gehören. ## Parameter - `id` (Path, required): Wartungsfenster-ID. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/maintenance-windows/5" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Antwort (Response) ```json { "id": 5, "websiteId": 101, "icmpMonitorId": null, "smtpMonitorId": null, "sshMonitorId": null, "ftpMonitorId": null, "imapPopMonitorId": null, "customerId": 12, "name": "Wöchentliche Wartung", "description": "Geplante Downtime", "startTime": "2026-02-25T02:00:00.000Z", "endTime": "2026-02-25T04:00:00.000Z", "isRecurring": true, "recurrencePattern": { "frequency": "weekly", "interval": 1, "daysOfWeek": [1] }, "isActive": true, "createdBy": "<user-id>", "createdAt": "2026-02-20T10:00:00.000Z", "updatedAt": "2026-02-20T10:00:00.000Z", "website": { "id": 101, "url": "https://example.com" } } ``` Hinweis: Je nach Ziel kann die Response stattdessen auch eine dieser Relationen enthalten: `icmpMonitor`, `smtpMonitor`, `sshMonitor`, `ftpMonitor`, `imapPopMonitor`. Verschachtelte `customer`-Objekte werden nicht zurückgegeben. ## Häufige Fehler - `400 Invalid maintenance window ID` wenn `:id` ungültig ist - `404 Maintenance window not found` wenn das Fenster nicht existiert - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf das Ziel/den Kunden hast - `500 Maintenance window target is missing` wenn kein gültiges Ziel am Wartungsfenster hinterlegt ist

### Wartungsfenster auflisten
URL: https://docs.uptimeify.io/de/api/website-configuration/list-maintenance-windows
Description: Gibt Wartungsfenster zurück, standardmäßig auf deine Organisation scoped.
Summary: `GET /api/maintenance-windows` Du kannst nach einem konkreten Ziel (z. B. `websiteId`) oder nach `customerId`/`organizationId` filtern. ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` ## Query Parameter - `websiteId` (optional) - `customerId` (optional) - `organizationId` (optional, Standard: deine Session-Organisation) - `activeOnly` (optional): `true` liefert nur aktive Fenster - Target-Filter (optional): `icmpMonitorId`, `smtpMonitorId`, `sshMonitorId`, `ftpMonitorId`, `imapPopMonitorId` Hinweis (API-Token Scope): Wenn du ein Customer-scoped API-Token nutzt, sind Ergebnisse auf diesen Kunden beschränkt. Ein anderer `customerId` liefert `403`. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/maintenance-windows?websiteId=101" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Antwort (Response) ```json [ { "id": 5, "websiteId": 101, "icmpMonitorId": null, "smtpMonitorId": null, "sshMonitorId": null, "ftpMonitorId": null, "imapPopMonitorId": null, "customerId": 12, "customerName": "Acme Corp", "name": "Wöchentliche Wartung", "description": "Geplante Downtime", "startTime": "2026-02-25T02:00:00.000Z", "endTime": "2026-02-25T04:00:00.000Z", "isRecurring": true, "recurrencePattern": { "frequency": "weekly", "interval": 1, "daysOfWeek": [1] }, "isActive": true, "createdBy": "<user-id>", "createdAt": "2026-02-20T10:00:00.000Z", "updatedAt": "2026-02-20T10:00:00.000Z", "website": { "id": 101, "url": "https://example.com" } } ] ``` Hinweis: Der List-Endpoint enthält nur die `website`-Relation (wenn `websiteId` gesetzt ist). Verschachtelte `customer`-Objekte und Monitor-Relationen sind in der Liste nicht enthalten. Für Anzeige und Filter steht stattdessen ein schlankes Top-Level-Feld `customerName` zur Verfügung. ## Häufige Fehler - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf das Ziel hast

### Check-Einstellungen aktualisieren
URL: https://docs.uptimeify.io/de/api/website-configuration/update-check-settings
Description: Konfiguriere, welche Aspekte der Website überwacht werden sollen.
Summary: `PATCH /api/websites/:websiteId/check-config` ## Anfrage (Request Body) ```json { "checkSslEnabled": true, "checkHttpsRedirectEnabled": true, "checkStatusEnabled": true, "checkSizeEnabled": true, "checkResponseTimeEnabled": true, "checkKeywordEnabled": false, "checkDomainExpiryEnabled": true, "minPageSize": 1024, // in Bytes (optional) "maxPageSize": 5242880 // in Bytes (optional) } ``` ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X PATCH \ "$BASE_URL/api/websites/101/check-config" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"checkSslEnabled":true,"checkHttpsRedirectEnabled":true,"checkStatusEnabled":true,"checkSizeEnabled":true,"checkResponseTimeEnabled":true,"checkKeywordEnabled":false,"minPageSize":1024,"maxPageSize":5242880}' ``` ## Beispiel-Antwort ```json { "success": true } ``` ## Häufige Fehler - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf die Website hast - `404 Website not found` wenn die Website nicht existiert

### Wartungsfenster aktualisieren
URL: https://docs.uptimeify.io/de/api/website-configuration/update-maintenance-window
Description: Aktualisiert ein bestehendes Wartungsfenster. Alle Felder sind optional (Partial Update).
Summary: `PATCH /api/maintenance-windows/:id` ## Authentifizierung Erfordert eine gültige Session. - Header: `Authorization: Bearer <token>` Hinweis: Global-Supporter dürfen keine Wartungsfenster aktualisieren (`403`). Read-only Nutzer dürfen es. ## Parameter - `id` (Path, required): Wartungsfenster-ID. ## Anfrage (Request Body) ```json { "name": "Server-Upgrade (updated)", "description": null, "startTime": "2026-02-25T03:00:00.000Z", "endTime": "2026-02-25T05:00:00.000Z", "isRecurring": true, "recurrencePattern": { "frequency": "weekly", "interval": 1, "daysOfWeek": [1] }, "isActive": true } ``` Hinweise: - Du kannst die Target-IDs (`websiteId`, `icmpMonitorId`, ...) nicht ändern. Es werden nur die Felder des Wartungsfensters aktualisiert. - `description` kann auf `null` gesetzt werden, um sie zu löschen. - Wenn du `startTime` und/oder `endTime` änderst, muss `endTime` nach `startTime` liegen. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X PATCH "$BASE_URL/api/maintenance-windows/5" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{"name":"Server-Upgrade (updated)","description":null,"startTime":"2026-02-25T03:00:00.000Z","endTime":"2026-02-25T05:00:00.000Z","isRecurring":true,"recurrencePattern":{"frequency":"weekly","interval":1,"daysOfWeek":[1]},"isActive":true}' ``` ## Antwort (Response) ```json { "id": 5, "websiteId": 101, "icmpMonitorId": null, "smtpMonitorId": null, "sshMonitorId": null, "ftpMonitorId": null, "imapPopMonitorId": null, "customerId": 12, "name": "Server-Upgrade (updated)", "description": null, "startTime": "2026-02-25T03:00:00.000Z", "endTime": "2026-02-25T05:00:00.000Z", "isRecurring": true, "recurrencePattern": { "frequency": "weekly", "interval": 1, "daysOfWeek": [1] }, "isActive": true, "createdBy": "<user-id>", "createdAt": "2026-02-20T10:00:00.000Z", "updatedAt": "2026-02-21T11:00:00.000Z" } ``` ## Häufige Fehler - `400 Invalid maintenance window ID` wenn `:id` ungültig ist - `400 End time must be after start time` wenn du `startTime`/`endTime` auf einen ungültigen Zeitraum setzt - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf das Wartungsfenster hast - `404 Maintenance window not found` wenn das Wartungsfenster nicht existiert

### Website-Verwaltung
URL: https://docs.uptimeify.io/de/api/websites
Description: Verwalte die überwachten Websites.
Summary: Pfadbasierte Website-Endpunkte verwenden `websitePublicId`-UUIDs. ## Endpunkte - [Websites auflisten](./websites-auflisten) - [Website erstellen](./website-erstellen) - [Website abrufen](./website-abfragen) - [Website-Details abrufen](./website-details-abfragen) - [Website aktualisieren](./website-aktualisieren) - [Status ändern](./website-status-wechseln) - [Website löschen](./website-loeschen)

### Status ändern
URL: https://docs.uptimeify.io/de/api/websites/change-status
Description: Ändert den Monitoring-Status einer Website.
Summary: `PATCH /api/websites/:websitePublicId` Es gibt keinen separaten `.../status` Endpoint — Status-Änderungen erfolgen über `PATCH /api/websites/:websitePublicId`. ## Anfrage (Request Body) ```json { "status": "maintenance" } ``` Erlaubte Werte: - `active` - `inactive` (du kannst auch `paused` senden, das wird zu `inactive` gemappt) - `maintenance` ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X PATCH "$BASE_URL/api/websites/6bfec6f6-245a-47ce-843b-157d97d56f88" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -H "Accept: application/json" \ -d '{ "status": "maintenance" }' ``` ## Häufige Fehler - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keine Schreibrechte hast (z.B. readonly/global supporter) - `403 Active website limit reached...` wenn ein Wechsel auf `active` das Limit überschreiten würde ## Antwort (Response) Gibt das aktualisierte Website-Objekt zurück. Siehe [Fehlerliste](/de/api/error-codes-and-known-pitfalls) für Fehlerantworten.

### Website erstellen
URL: https://docs.uptimeify.io/de/api/websites/create-website
Description: Erstellt einen neuen Website-Monitor für einen Kunden.
Summary: `POST /api/websites` ## Anfrage (Request Body) ```json { "customerId": "059e1469-0f05-4c93-bd4d-89c45bb2afd9", "name": "Neue Landing Page", "url": "https://landing.example.com", "checkInterval": 60 // Optional, Standardwert aus Paket-Limit } ``` `customerId` akzeptiert die Public ID des Kunden (bevorzugt) und weiterhin Legacy-Nummern. Optional kann `managementType` (`managed` oder `self_service`, Standard `managed`) gesetzt werden — siehe [Managed vs. Self-Service](/de/monitoring/managed-vs-self-service). Nur Organisations-Admins dürfen die Klasse wählen; kunden-gescopte Ersteller erhalten immer `self_service` (erfordert `allowSelfService` und freies Kontingent). ## Antwort (Response) ```json { "id": 103, "customerId": 1, "name": "Neue Landing Page", "url": "https://landing.example.com", "status": "active", "createdAt": "2023-10-27T10:05:00Z" } ``` ## Häufige Fehler - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keine Berechtigung für den Kunden oder die Organisation hast - `403 Forbidden` (`selfServiceNotAllowed`), wenn ein kunden-gescopter Aufrufer einen Monitor anlegt, aber das aufgelöste `allowSelfService` des Kunden false ist - `403 Forbidden` (`selfServiceQuotaReached`), wenn die Gesamtzahl der Self-Service-Monitore des Kunden (über alle Monitor-Typen) `maxSelfServiceUrls` bereits erreicht - `404 Customer not found` wenn `customerId` keinem existierenden Kunden zugeordnet werden kann

### Website löschen
URL: https://docs.uptimeify.io/de/api/websites/delete-website
Description: Entfernt eine Website und ihren Monitoring-Verlauf unwiderruflich.
Summary: `DELETE /api/websites/:websitePublicId` ## Antwort (Response) Gibt `204 No Content` zurück. Siehe [Fehlerliste](/de/api/error-codes-and-known-pitfalls) für Fehlerantworten.

### Website abrufen
URL: https://docs.uptimeify.io/de/api/websites/get-website
Description: Gibt eine einzelne Website (basic/sanitized) zurück. Sensible Felder wie verschlüsselte Credentials werden entfernt.
Summary: `GET /api/websites/:websitePublicId` Wenn du die vollständigen “Mega”-Details (inkl. zusätzlicher Felder) brauchst, nutze: - `GET /api/websites/:websitePublicId/details` ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/websites/9a3d4d4d-7a4b-4f37-a9df-2a6f6d9d7a10" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Antwort (Response) ```json { "id": 101, "organizationId": 1, "customerId": 1, "name": "Haupt-Marketing-Seite", "url": "https://example.com", "status": "active", "monitoringType": "combined", "checkInterval": 1, "createdAt": "2026-02-26T12:00:00.000Z", "updatedAt": "2026-02-26T12:00:00.000Z" } ``` ## Häufige Fehler - `400 Website public ID (UUID) required` wenn `:websitePublicId` fehlt/ungültig ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf die Website hast - `404 Not Found` wenn die Website nicht existiert

### Website-Details abrufen
URL: https://docs.uptimeify.io/de/api/websites/get-website-details
Description: Gibt die Daten für die Website-Detailseite in einem Call zurück (Mega-Endpoint).
Summary: `GET /api/websites/:websitePublicId/details` ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/websites/9a3d4d4d-7a4b-4f37-a9df-2a6f6d9d7a10/details?range=day" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Query Parameter - `range` (optional): `day` | `week` | `month` | `year` (Standard: `day`) ## Antwort (Response) ```json { "website": { "id": 101, "name": "Haupt-Marketing-Seite", "url": "https://example.com", "status": "active", "monitoringType": "combined", "customerId": 1 }, "uptimeStats": { "day": "100.00", "month": "99.95", "year": "99.90", "dayAvgResponse": 125, "monthAvgResponse": 118, "yearAvgResponse": 120 }, "monitoringData": { "responseTimeData": [], "statusData": [], "uptimePercentage": "99.95", "checkSuccessRatePercentage": "99.80", "totalChecks": 100, "successfulChecks": 99 }, "incidents": { "history": [], "total": 0, "ongoing": 0, "totalDowntime": "0m" }, "alerts": { "history": [], "total": 0, "notificationContext": null }, "maintenance": { "inMaintenance": false, "activeWindows": [], "allWindows": [] } } ``` ## Häufige Fehler - `400 Invalid website public ID (UUID)` wenn `:websitePublicId` ungültig ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf die Website hast - `500 Failed to fetch website details` bei Serverfehlern

### Websites auflisten
URL: https://docs.uptimeify.io/de/api/websites/list-websites
Description: Listet Websites innerhalb einer Organisation auf (paginiert). Die Ergebnisse sind durch deine Session/Permissions eingeschränkt.
Summary: `GET /api/websites` ## Query Parameter - `organizationId` (optional): Standard ist deine Session-Organisation. - `customerId` (optional): Filtert nach Kunde. - `search` (optional): Suche nach Website-/Kundenfeldern. - `monitoringType` (optional): `combined` | `http_status` | `ssl_check` | `playwright` | `heartbeat` | `dns` - `excludeMonitoringType` (optional): wie `monitoringType` - `page` (optional, Standard: `1`) - `perPage` (optional, Standard: `50`, max: `200`) ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X GET "$BASE_URL/api/websites?organizationId=1&page=1&perPage=50" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Antwort (Response) ```json { "items": [ { "id": 101, "publicId": "11111111-1111-4111-8111-111111111111", "customerId": 1, "customerPublicId": "22222222-2222-4222-8222-222222222222", "customerName": "Acme Corp", "name": "Haupt-Marketing-Seite", "url": "https://example.com", "status": "active", "monitoringType": "combined", "checkInterval": 1, "createdAt": "2026-02-26T12:00:00.000Z" } ], "total": 1, "page": 1, "perPage": 50 } ``` Jedes Item enthält flache Felder `customerName` und `customerPublicId`, aber kein vollständig eingebettetes `customer`-Objekt. ## Häufige Fehler - `400 Invalid customerId` wenn `customerId` ungültig ist - `400 Invalid monitoringType` wenn `monitoringType` nicht unterstützt wird - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Zugriff auf die Organisation hast

### Website-Check triggern
URL: https://docs.uptimeify.io/de/api/websites/trigger-check
Description: Löst einen sofortigen Check einer Website über die geeigneten Monitoring-Standorte aus.
Summary: `POST /api/websites/:websitePublicId/trigger-check` ## Authentifizierung Erfordert eine gültige Session mit Schreibzugriff auf die Website. - Header: `Authorization: Bearer <token>` ## Parameter - `websitePublicId` (Pfad, erforderlich): Öffentliche UUID der Website. ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X POST \ "$BASE_URL/api/websites/6bfec6f6-245a-47ce-843b-157d97d56f88/trigger-check" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ## Beispiel-Antwort ```json { "success": true, "message": "Check triggered successfully", "websiteId": 123 } ``` Der Check wird für die aktiven Monitoring-Standorte der Website eingereiht; die Ergebnisse erscheinen wenige Sekunden später in der Check-Historie. ## Häufige Fehler - `400 Website public ID (UUID) required` wenn `:websitePublicId` ungültig ist - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keinen Schreibzugriff auf die Website hast - `503 No active monitoring locations available`

### Website aktualisieren
URL: https://docs.uptimeify.io/de/api/websites/update-website
Description: PATCH /api/websites/:websitePublicId oder PUT /api/websites/:websitePublicId
Summary: `PATCH /api/websites/:websitePublicId` Aktualisiert die Konfiguration eines Website-Monitors. - `PATCH` eignet sich für Teil-Updates (nur gesendete Felder werden geändert). - `PUT` ist stärker validiert (Schema-Validierung) und eignet sich für umfangreichere Updates. ## Anfrage (Request Body) - `customerId` optional für `PATCH`, aber erforderlich für Full-Update-Anfragen; akzeptiert Customer Public ID (bevorzugt) oder Legacy-Nummer - `managementType` (`managed` oder `self_service`) — Ownership-Klasse, siehe [Managed vs. Self-Service](/de/monitoring/managed-vs-self-service). Der Klassen-Wechsel ist Organisations-Admins vorbehalten; das Umstellen auf `self_service` erfordert `allowSelfService` und freies Kontingent. ```json { "name": "Aktualisierter Name", "url": "https://new-url.example.com", "checkInterval": 5, "timeoutSeconds": 10 } ``` ## Beispiel (cURL) ```bash BASE_URL="https://uptimeify.io" TOKEN="<dein-api-token>" curl -X PATCH "$BASE_URL/api/websites/9a3d4d4d-7a4b-4f37-a9df-2a6f6d9d7a10" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -H "Accept: application/json" \ -d '{ "name": "Aktualisierter Name", "checkInterval": 5 }' ``` ## Häufige Fehler - `401 Unauthorized` wenn du nicht angemeldet bist - `403 Forbidden` wenn du keine Schreibrechte hast - `403 Forbidden` (`managed_by_organization`), wenn ein kunden-gescopter Aufrufer einen `managed`-Monitor ohne die `canEditManaged`-Ausnahme bearbeitet - `403 Forbidden` (`managementTypeOrgOnly`), wenn ein Nicht-Org-Admin `managementType` ändern will - `403 Forbidden` (`selfServiceQuotaReached`), wenn das Umstellen auf `self_service` das Kontingent des Kunden überschreiten würde - `404 Customer not found` wenn `customerId` keinem existierenden Kunden zugeordnet werden kann ## Antwort (Response) Gibt das aktualisierte Website-Objekt zurück. Siehe [Fehlerliste](/de/api/error-codes-and-known-pitfalls) für Fehlerantworten.

### White-Label & Branding
URL: https://docs.uptimeify.io/de/api/whitelabel
Description: Passe Produktname, Theme-Farben, Logos, Favicons und eigene Domains deiner Organisation an. Alle White-Label-Endpunkte erfordern die Admin- oder Global-Admin-Rolle.
Summary: ## Authentifizierung Alle White-Label-Endpunkte erfordern eine Session-Authentifizierung (keine API-Tokens): ```bash BASE_URL="https://uptimeify.io" ``` ## Endpunkte ### Branding - [Branding abrufen](./get-branding) - [Branding aktualisieren](./update-branding) - [Branding-Asset hochladen](./upload-branding) ### Domains - [Domains auflisten](./list-domains) - [Domain hinzufügen](./add-domain) - [Domain verifizieren](./verify-domain) - [Domain aktivieren](./activate-domain) - [Domain löschen](./delete-domain)

### Domain aktivieren
URL: https://docs.uptimeify.io/de/api/whitelabel/activate-domain
Description: Aktiviert eine verifizierte eigene Domain. Optional wird sie als primäre Domain gesetzt. Nur für Admins.
Summary: `POST /api/organization/whitelabel/domains/activate` ## Anfrage (Request Body) | Feld | Typ | Pflicht | Standard | Beschreibung | |-------|------|----------|---------|-------------| | `domainId` | number | Ja | — | Die ID der verifizierten Domain, die aktiviert werden soll | | `makePrimary` | boolean | Nein | auto | Setzt diese Domain als primär. Wird automatisch auf `true` gesetzt, wenn keine primäre Domain existiert. | ## Beispiel (cURL) ```bash curl -X POST "$BASE_URL/api/organization/whitelabel/domains/activate" \ -H "Cookie: $SESSION_COOKIE" \ -H "Content-Type: application/json" \ -d '{ "domainId": 2, "makePrimary": true }' ``` ## Antwort (Response) ```json { "activated": true, "domain": { "id": 2, "hostname": "app.example.com", "status": "active", "role": "app", "isPrimary": true, "verificationToken": "xyz789-abc456", "verifiedAt": "2026-04-15T12:30:00.000Z", "createdAt": "2026-04-15T12:00:00.000Z", "updatedAt": "2026-04-15T13:00:00.000Z" } } ``` ## Häufige Fehler - `400 Domain must be verified before activation` - `404 Domain not found`

### Domain hinzufügen
URL: https://docs.uptimeify.io/de/api/whitelabel/add-domain
Description: Fügt eine eigene Domain für White-Label hinzu. Erstellt einen ausstehenden DNS-Verifizierungseintrag. Die erste Domain wird automatisch als primär gesetzt. Erfordert die Admin-Rolle.
Summary: `POST /api/organization/whitelabel/domains` ## Anfrage (Request Body) | Feld | Typ | Pflicht | Beschreibung | |-------|------|----------|-------------| | `hostname` | string | Ja | Hostname der eigenen Domain (3–253 Zeichen). Keine Wildcards. | ## Beispiel (cURL) ```bash curl -X POST "$BASE_URL/api/organization/whitelabel/domains" \ -H "Cookie: $SESSION_COOKIE" \ -H "Content-Type: application/json" \ -d '{ "hostname": "app.example.com" }' ``` ## Antwort (Response) ```json { "domain": { "id": 2, "hostname": "app.example.com", "status": "pending", "role": "app", "isPrimary": false, "verificationToken": "xyz789-abc456", "verifiedAt": null, "createdAt": "2026-04-15T12:00:00.000Z", "updatedAt": "2026-04-15T12:00:00.000Z" }, "dns": { "txtName": "_uptimeify-verify.app.example.com", "txtValue": "xyz789-abc456" } } ``` Lege einen DNS-TXT-Eintrag mit `txtName` und `txtValue` an und rufe anschließend [Domain verifizieren](./verify-domain) auf. ## Häufige Fehler - `400 Invalid hostname` wenn das Hostname-Format falsch ist - `400 This hostname is reserved` wenn der Hostname mit der Hauptplattform übereinstimmt - `400 Wildcard domains are not supported` - `409 Hostname already exists`

### Domain löschen
URL: https://docs.uptimeify.io/de/api/whitelabel/delete-domain
Description: Löscht eine eigene Domain. War die gelöschte Domain die primäre, wird die nächste verfügbare Domain zur primären befördert. Nur für Admins.
Summary: `DELETE /api/organization/whitelabel/domains/:id` ## Beispiel (cURL) ```bash curl -X DELETE "$BASE_URL/api/organization/whitelabel/domains/2" \ -H "Cookie: $SESSION_COOKIE" ``` ## Antwort (Response) ```json { "success": true } ``` ## Häufige Fehler - `401 Unauthorized` wenn nicht authentifiziert - `403 Forbidden` wenn kein Admin - `404 Domain not found`

### Branding abrufen
URL: https://docs.uptimeify.io/de/api/whitelabel/get-branding
Description: Gibt die Branding-Konfiguration der Organisation zurück, einschließlich Produktname, Theme-Farben sowie signierter URLs für Logos und Favicons. Erfordert die Admin-Rolle.
Summary: `GET /api/organization/whitelabel/branding` ## Beispiel (cURL) ```bash curl -X GET "$BASE_URL/api/organization/whitelabel/branding" \ -H "Cookie: $SESSION_COOKIE" \ -H "Accept: application/json" ``` ## Antwort (Response) ```json { "branding": { "productName": "Acme Monitor", "hideProductName": false, "logoObjectKey": "branding/org-1/logo/light/1710000000-logo.svg", "logoObjectKeyLight": "branding/org-1/logo/light/1710000000-logo.svg", "logoObjectKeyDark": "branding/org-1/logo/dark/1710000000-logo-dark.svg", "hideLogos": false, "faviconObjectKey": "branding/org-1/favicon/light/1710000000-favicon.ico", "faviconObjectKeyLight": "branding/org-1/favicon/light/1710000000-favicon.ico", "faviconObjectKeyDark": "branding/org-1/favicon/dark/1710000000-favicon-dark.ico", "themePrimary": "#43B1AE", "themeSecondary": null, "logoUrl": "https://s3.example.com/branding/org-1/logo/light/1710000000-logo.svg?...", "logoLightUrl": "https://s3.example.com/branding/org-1/logo/light/1710000000-logo.svg?...", "logoDarkUrl": "https://s3.example.com/branding/org-1/logo/dark/1710000000-logo-dark.svg?...", "faviconUrl": "https://s3.example.com/branding/org-1/favicon/light/1710000000-favicon.ico?...", "faviconLightUrl": "https://s3.example.com/branding/org-1/favicon/light/1710000000-favicon.ico?...", "faviconDarkUrl": "https://s3.example.com/branding/org-1/favicon/dark/1710000000-favicon-dark.ico?...", "updatedAt": "2026-03-01T10:00:00.000Z" } } ``` ## Häufige Fehler - `401 Unauthorized` wenn nicht authentifiziert - `403 Forbidden` wenn kein Admin

### Domains auflisten
URL: https://docs.uptimeify.io/de/api/whitelabel/list-domains
Description: Gibt alle eigenen App-Domains der Organisation zurück. Es werden nur Domains mit der Rolle app zurückgegeben. Erfordert die Admin-Rolle.
Summary: `GET /api/organization/whitelabel/domains` ## Beispiel (cURL) ```bash curl -X GET "$BASE_URL/api/organization/whitelabel/domains" \ -H "Cookie: $SESSION_COOKIE" \ -H "Accept: application/json" ``` ## Antwort (Response) ```json { "domains": [ { "id": 1, "hostname": "app.example.com", "status": "active", "role": "app", "isPrimary": true, "verificationToken": "abc123-def456", "verifiedAt": "2026-01-15T10:00:00.000Z", "createdAt": "2026-01-14T08:00:00.000Z", "updatedAt": "2026-01-15T10:00:00.000Z" } ] } ``` ## Häufige Fehler - `401 Unauthorized` wenn nicht authentifiziert - `403 Forbidden` wenn kein Admin

### Branding aktualisieren
URL: https://docs.uptimeify.io/de/api/whitelabel/update-branding
Description: Aktualisiert die Branding-Konfiguration der Organisation. Alle Felder sind optional — nur gesendete Felder werden aktualisiert. Wird productName oder eine Theme-Farbe auf null gesetzt, wird sie geleert. Erfordert die Admin-Rolle.
Summary: `PATCH /api/organization/whitelabel/branding` Theme-Farben akzeptieren CSS-Custom-Property-Tokens (z.B. `--color-red-500`) oder Hex-Farben (z.B. `#43B1AE`). Ungültige Werte werden abgelehnt. ## Anfrage (Request Body) (alle optional) | Feld | Typ | Beschreibung | |-------|------|-------------| | `productName` | string\|null | Anzeigename des Produkts (1–80 Zeichen). `null` leert ihn. | | `hideProductName` | boolean | Blendet den Produktnamen in der UI aus | | `hideLogos` | boolean | Blendet alle Logos in der UI aus | | `themePrimary` | string\|null | Primäre Theme-Farbe (Hex oder CSS-Variable). `null` leert sie. | | `themeNeutral` | string\|null | Neutrale/sekundäre Theme-Farbe (Hex oder CSS-Variable). `null` leert sie. | ## Beispiel (cURL) ```bash curl -X PATCH "$BASE_URL/api/organization/whitelabel/branding" \ -H "Cookie: $SESSION_COOKIE" \ -H "Content-Type: application/json" \ -d '{ "productName": "Acme Monitor", "themePrimary": "#43B1AE", "hideProductName": false }' ``` ## Antwort (Response) ```json { "branding": { "productName": "Acme Monitor", "hideProductName": false, "hideLogos": false, "themePrimary": "#43B1AE", "themeSecondary": null, "updatedAt": "2026-04-15T12:00:00.000Z" } } ``` ## Häufige Fehler - `401 Unauthorized` wenn nicht authentifiziert - `403 Forbidden` wenn kein Admin

### Branding-Asset hochladen
URL: https://docs.uptimeify.io/de/api/whitelabel/upload-branding
Description: Lädt ein Logo oder Favicon als Base64-Data-URL hoch. Assets werden in S3 gespeichert und der Branding-Datensatz wird automatisch aktualisiert. Erfordert die Admin-Rolle.
Summary: `POST /api/organization/whitelabel/branding/upload` **Logo**-Typen: `logo`, `logoLight`, `logoDark` — akzeptiert PNG, JPEG, WebP, SVG (max. 2 MB). **Favicon**-Typen: `favicon`, `faviconLight`, `faviconDark` — akzeptiert PNG, SVG, ICO (max. 512 KB). Das Legacy-`logo` wird als `logoLight` behandelt und `favicon` als `faviconLight`. ## Anfrage (Request Body) | Feld | Typ | Pflicht | Beschreibung | |-------|------|----------|-------------| | `kind` | string | Ja | `logo`, `logoLight`, `logoDark`, `favicon`, `faviconLight`, `faviconDark` | | `fileName` | string | Ja | Ursprünglicher Dateiname (1–200 Zeichen) | | `dataUrl` | string | Ja | Base64-Data-URL (`data:*/*;base64,...`) | ## Beispiel (cURL) ```bash curl -X POST "$BASE_URL/api/organization/whitelabel/branding/upload" \ -H "Cookie: $SESSION_COOKIE" \ -H "Content-Type: application/json" \ -d '{ "kind": "logoLight", "fileName": "logo.svg", "dataUrl": "data:image/svg+xml;base64,PHN2Zy..." }' ``` ## Antwort (Response) ```json { "success": true, "uploaded": { "kind": "logo", "objectKey": "branding/org-1/logo/light/1710000000-logo.svg", "contentType": "image/svg+xml", "bytes": 1234, "publicUrl": "https://s3.example.com/branding/org-1/logo/light/1710000000-logo.svg?..." }, "branding": { "productName": "Acme Monitor", "hideProductName": false, "logoUrl": "https://s3.example.com/...", "themePrimary": "#43B1AE", "updatedAt": "2026-04-15T12:00:00.000Z" } } ``` ## Häufige Fehler - `400 Invalid dataUrl` wenn das Data-URL-Format falsch ist - `400 Unsupported contentType` wenn der Content-Type für den Asset-Typ nicht erlaubt ist - `413 File too large` wenn die Größenbeschränkungen überschritten werden - `503 Whitelabel asset storage is not configured` wenn S3 nicht eingerichtet ist

### Domain verifizieren
URL: https://docs.uptimeify.io/de/api/whitelabel/verify-domain
Description: Verifiziert die DNS-TXT-Einträge für eine eigene Domain. Nur für Admins.
Summary: `POST /api/organization/whitelabel/domains/verify` ## Anfrage (Request Body) | Feld | Typ | Pflicht | Beschreibung | |-------|------|----------|-------------| | `domainId` | number | Ja | Die ID der zu verifizierenden Domain | ## Beispiel (cURL) ```bash curl -X POST "$BASE_URL/api/organization/whitelabel/domains/verify" \ -H "Cookie: $SESSION_COOKIE" \ -H "Content-Type: application/json" \ -d '{ "domainId": 2 }' ``` ## Antwort (Response) (Erfolg) ```json { "verified": true, "status": "verified", "domain": { "id": 2, "hostname": "app.example.com", "status": "verified", "role": "app", "isPrimary": false, "verificationToken": "xyz789-abc456", "verifiedAt": "2026-04-15T12:30:00.000Z", "createdAt": "2026-04-15T12:00:00.000Z", "updatedAt": "2026-04-15T12:30:00.000Z" } } ``` ## Häufige Fehler - `400 TXT verification failed (token not found)` wenn der DNS-Eintrag fehlt oder einen falschen Wert hat - `400 Domain has no verification token` - `404 Domain not found`

## Examples

### Beispiele
URL: https://docs.uptimeify.io/de/examples
Description: Diese Seite ist in die API-Dokumentation umgezogen.
Summary: Weiter hier: - [Beispiele (API)](/de/api/examples) - [Kunde + Website erstellen](/de/api/examples/create-customer-and-website) - [Kunde inkl. aller Websites löschen](/de/api/examples/delete-customer-and-all-websites) - [Kunde + alle Monitore anlegen](/de/api/examples/create-customer-and-all-monitors) - [Kunde + mehrere Monitore anlegen](/de/api/examples/create-customer-and-multiple-monitors)

### Kunde + alle Monitore anlegen
URL: https://docs.uptimeify.io/de/examples/create-customer-and-all-monitors
Description: Diese Seite ist in die API-Dokumentation umgezogen.
Summary: Weiter hier: - [Kunde + alle Monitore anlegen (API)](/de/api/examples/create-customer-and-all-monitors)

### Kunde + mehrere Monitore anlegen
URL: https://docs.uptimeify.io/de/examples/create-customer-and-multiple-monitors
Description: Diese Seite ist in die API-Dokumentation umgezogen.
Summary: Weiter hier: - [Kunde + mehrere Monitore anlegen (API)](/de/api/examples/create-customer-and-multiple-monitors)

### Kunde + Website erstellen
URL: https://docs.uptimeify.io/de/examples/create-customer-and-website
Description: Diese Seite ist in die API-Dokumentation umgezogen.
Summary: Weiter hier: - [Kunde + Website erstellen (API)](/de/api/examples/create-customer-and-website)

### Kunde inkl. aller Websites löschen
URL: https://docs.uptimeify.io/de/examples/delete-customer-and-all-websites
Description: Diese Seite ist in die API-Dokumentation umgezogen.
Summary: Weiter hier: - [Kunde inkl. aller Websites löschen (API)](/de/api/examples/delete-customer-and-all-websites) - [Kunde inkl. aller Websites löschen (API)](/de/api/examples/delete-customer-and-all-websites)

## Incidents

### Vorfälle
URL: https://docs.uptimeify.io/de/incidents
Description: Vorfälle werden automatisch erstellt, wenn das Monitoring ein Problem mit einer Website oder einem Service erkennt. Sie sind die Grundlage für Alarmierung, Reporting und die öffentlichen Statusseiten.
Summary: ## Wo Sie Vorfälle finden - **Vorfall-Übersicht**: `/incidents` - **Pro Website / Monitor**: Die meisten Detailseiten haben einen Tab mit der Vorfall-Historie ## Vorfall-Lebenszyklus Vorfälle haben zwei primäre Zustände: - `open` — das Problem besteht noch - `resolved` — der Service hat sich erholt und der Vorfall wurde geschlossen (automatisch, sobald die Checks wieder bestehen) ## Was ein Vorfall enthält Je nach Check-Typ kann ein Vorfall enthalten: - **Typ / Schweregrad** — z.B. `downtime`, `http_status`, `performance`, `ssl_warning`, `ssl_expiry` - **Start- / Lösungszeit** - **HTTP-Statuscode** (falls zutreffend) - **Antwortzeit (ms)** (falls zutreffend) - **Fehlermeldung** — Netzwerkfehler, Timeouts, Parsing-Fehler usw. - **Zeitstempel der letzten Benachrichtigung** — für Benachrichtigungs-Erinnerungen ## Vorfall-Details (Timeline & Beleg) Öffnen Sie aus der Vorfall-Liste das **Detail-Modal**, um Folgendes zu sehen: - Eine **Timeline** von Bestätigung → Ausfall → Wiederherstellung - Den **Beleg-Check** (der Monitoring-Check, der als Nachweis diente) - Einen optionalen **Traceroute-Auszug** - Einen optionalen **Screenshot** (falls verfügbar) Das beantwortet „Was genau ist passiert?" ohne Wühlen in Rohlogs. ## Wie Vorfälle den Statusseiten-Status bestimmen Wenn der Kunde eine öffentliche [Statusseite](/status-pages) hat, ändern offene Vorfälle den angezeigten Service-Status: | Vorfall-Situation | Statusseiten-`state` | |-------------------|----------------------| | Keine offenen Vorfälle | `operational` | | Nur **SSL-Warnung**-Vorfälle offen | `warning` | | Jeder andere offene Vorfall (downtime, http_status, performance, …) | `degraded` | | Aktives Wartungsfenster, keine offenen Vorfälle | `maintenance` | Das Gesamt-Banner der Seite spiegelt den schwerwiegendsten Status über alle Services wider. Siehe [Statusseiten → Wie der öffentliche Status abgeleitet wird](/status-pages#wie-der-öffentliche-status-abgeleitet-wird). ## Nicht eindeutige Checks (Browser-Verifizierungs-Timeouts) Manche Seiten nutzen Bot-Schutz / Browser-Verifizierung, die in einen Timeout laufen kann. In diesen Fällen markiert Uptimeify einen Check als **nicht eindeutig**, statt ihn als vollständigen Ausfall zu werten — so erhalten Sie keine irreführenden „alles ist down"-Alarme und -Vorfälle durch eine Schutz-Challenge statt eines echten Ausfalls.

## Integrations

### Integrationen
URL: https://docs.uptimeify.io/de/integrations
Description: Uptimeify stellt Alarme in den Tools zu, die Sie ohnehin nutzen — Chat, On-Call, Issue-Tracker und mehr — plus Firewall-Whitelisting und eine vollständige REST-API.
Summary: ## Benachrichtigungskanäle Stellen Sie Alarme dort zu, wo Ihr Team arbeitet. Kanäle werden pro Kunde konfiguriert und an Ihre Benachrichtigungsregeln gehängt. - In der App unter den **Benachrichtigungs**-Einstellungen des Kunden verwalten. - Automatisieren mit der [Benachrichtigungskanäle-API](/de/api/notification-channels) (Kanal anlegen, auflisten, aktualisieren, löschen und **testen**). Jeder Kanal unten wird out of the box unterstützt. ### Direkt | Kanal | Zustellung über | Sie hinterlegen | |-------|-----------------|-----------------| | **E-Mail** | E-Mail | Empfängeradresse(n); fällt auf die Kunden-/Org-E-Mail zurück | | **SMS** | Textnachricht | Telefonnummer(n); fällt auf die Kunden-/Org-Nummer zurück | | **Webhook** | Ihren HTTP-Endpunkt | Endpunkt-URL (optional eigene Header und JSON-Body-Vorlage) | ### Chat & Zusammenarbeit | Kanal | Sie hinterlegen | |-------|-----------------| | **Slack** | Incoming-Webhook-URL (optional Username, Icon, Farbe) | | **Microsoft Teams** | Incoming-Webhook-URL | | **Discord** | Incoming-Webhook-URL (optional Username, Farbe) | | **Telegram** | Bot-Token + Chat-ID | | **Google Chat** | Incoming-Webhook-URL | | **Mattermost** | Incoming-Webhook-URL | | **Rocket.Chat** | Incoming-Webhook-URL | | **Matrix** | Homeserver-URL + Room-ID + Access-Token | | **Lark / Feishu** | Incoming-Webhook-URL | | **DingTalk** | Incoming-Webhook-URL (Access-Token in der URL) | | **WeCom** | Incoming-Webhook-URL (Key in der URL) | ### On-Call & Incident-Response | Kanal | Sie hinterlegen | |-------|-----------------| | **PagerDuty** | Events-API-v2-Routing-Key | | **Opsgenie** | API-Key + Region (EU/US), optional Priorität | | **ilert** | Integration-Key | | **Grafana OnCall** | Incoming-Webhook-URL | | **Squadcast** | Incoming-Webhook-URL (Token in der URL) | | **incident.io** | Alert-Source-URL + Bearer-Token | | **All Quiet** | Inbound-Webhook-URL (die URL ist das Geheimnis) | ### Push & Leichtgewichtig | Kanal | Sie hinterlegen | |-------|-----------------| | **Pushover** | User-Key + API-Token | | **ntfy** | Topic-URL (optional Access-Token) | | **Gotify** | Server-URL + App-Token | ### Issue-Tracker & ITSM | Kanal | Sie hinterlegen | |-------|-----------------| | **Jira** | Basis-URL + E-Mail + Projekt-Key + Issue-Typ + API-Token | | **GitHub** | Repository + Token (PAT); optional Enterprise-API-Basis-URL | | **GitLab** | Projekt-ID + Token; optional Basis-URL (self-hosted) | | **Linear** | Team-ID + API-Key | | **ServiceNow** | Instance-URL + Benutzername + Passwort | ## Eskalationsrichtlinien Definieren Sie mehrstufige, zeitbasierte Eskalation, sodass ein nicht bestätigter Alarm automatisch an den nächsten Verantwortlichen weitergegeben wird. - Konfigurieren und testen über die [Eskalations-API](/de/api/escalation). ## Firewall-Whitelisting Wenn Ihre Seite hinter einer Firewall oder WAF liegt, whitelisten Sie unsere Monitoring-Nodes, damit Checks nicht blockiert werden. - Siehe [Firewall-Whitelisting](/de/integrations/firewall) für das Dashboard und den `GET /api/ips`-Endpunkt. - Die vollständige Node-Liste steht unter [/ips.txt](https://uptimeify.io/ips.txt). Andere Anbieter whitelisten? Siehe [Monitoring-IP-Whitelists](https://uptimeify.io/de/vergleich/uptimerobot/test-ips). ## API & Automatisierung Alles oben — und der Rest der Plattform — ist skriptbar. - Beginnen Sie mit der [API-Dokumentation](/de/api). - Erzeugen Sie ein Token unter Ihrem Konto und authentifizieren Sie sich mit `Authorization: Bearer wsm_<token>`.

### Firewall-Allowlisting (Monitoring-Node-IPs)
URL: https://docs.uptimeify.io/de/integrations/firewall
Description: Wenn deine Website durch eine Firewall oder WAF geschützt ist, musst du ggf. unsere Monitoring-Nodes allowlisten, damit wir dein Endpoint zuverlässig erreichen können.
Summary: ## Dashboard (UI) Die aktuelle Allowlist findest du im Dashboard in der Sidebar unter „IP Adressen“. ## API (Automatisierung) Für automatischen Abruf gibt es einen authentifizierten Endpoint: - `GET /api/ips` ### Authentifizierung Nutze einen API-Token aus dem Dashboard. ```bash BASE_URL="https://uptimeify.io" TOKEN="wsm_<dein-api-token>" curl -H "Authorization: Bearer $TOKEN" "$BASE_URL/api/ips" ``` ### Antwort ```json { "ipv4": ["203.0.113.10"], "ipv6": ["2001:db8::10"], "locations": { "de-nbg": ["203.0.113.10"] }, "updated_at": "2026-01-01T00:00:00.000Z", "documentation": "https://uptimeify.io/docs/integrations/firewall" } ``` Hinweise: - Die IP-Liste kann sich ändern. Bitte nicht dauerhaft hardcoden. - Besser: regelmäßig synchronisieren (z.B. per Cronjob).

## Maintenance

### Wartung
URL: https://docs.uptimeify.io/de/maintenance
Description: Mit Wartungsfenstern planen Sie Arbeiten (Deployments, Updates, Migrationen), ohne störende Alarme auszulösen. Während eines aktiven Fensters gilt das betroffene Ziel als in Wartung — Alarme werden unterdrückt, und wenn der Kunde eine Statusseite hat, wird der Service als Wartung statt Beeinträchtigt angezeigt.
Summary: ## Wartungsfenster erstellen Gehen Sie zu **Dashboard → Wartung** und erstellen Sie ein neues Fenster. Benutzer mit Lesezugriff können Wartungsfenster für die ihnen zugewiesenen Kunden anlegen, bearbeiten, reaktivieren und löschen. Globale Support-Konten können Wartungsfenster nicht ändern. | Einstellung | Beschreibung | |-------------|--------------| | **Ziel** | Eines oder mehrere: eine **Website**, ein **Service-Monitor** (ICMP / SMTP / SSH / FTP / IMAP-POP), ein **DNS-Monitor**, eine Reihe von **Tags** oder der gesamte **Kunde**. Siehe [Mehrere Monitore oder Tag-basiert](#mehrere-monitore-oder-tag-basiert). | | **Name** | Eine freundliche Bezeichnung, z.B. „Wöchentliche Updates". | | **Beschreibung** | Optionale Notizen, die in der Historie erscheinen. | | **Start / Ende** | Der Zeitraum des Fensters. Zeiten werden in Ihrer Zeitzone interpretiert. | | **Aktiv** | Schalter zum Aktivieren/Deaktivieren ohne Löschen. | ## Mehrere Monitore oder Tag-basiert Ein einzelnes Wartungsfenster kann viele Monitore gleichzeitig abdecken: **Multi-Monitor-Auswahl im Formular** Im Wartungsfenster-Formular öffnen Sie den **Ziel**-Selektor und wählen beliebige Kombinationen von Websites und Service-Monitoren aus. Alle ausgewählten Monitore werden dem Fenster hinzugefügt; sie müssen alle zum selben Kunden gehören. **Bulk-„Wartung setzen" aus Monitor-Listen** Auf jeder Monitor-Listenseite (z.B. *Dashboard → Web*, *Dashboard → Server*) können Sie mehrere Zeilen über die Checkboxen auswählen und dann **Wartung setzen** aus der Bulk-Aktionsleiste wählen. Dadurch wird ein einzelnes Wartungsfenster erstellt, das alle ausgewählten Monitore auf einmal abdeckt, und das Formular wird mit diesen Monitoren als Ziele vorausgefüllt. **Dynamische Tag-basierte Fenster** Anstelle von (oder zusätzlich zu) einzelnen Monitoren können Sie einen oder mehrere **Tags** auswählen. Ein tag-basiertes Fenster deckt jeden Monitor ab, der den Tag aktuell trägt — und bleibt automatisch aktuell: - Ein Monitor, der **nach** der Fenstererstellung getaggt wird, wird automatisch abgedeckt; keine Aktualisierung erforderlich. - Das **Entfernen eines Tags** von einem Monitor beendet die Abdeckung sofort. **Organisationsweiter Geltungsbereich:** Werden Tags *ohne* explizite Monitore und ohne Kunden-Kontext ausgewählt, gilt das Fenster **organisationsweit** — es deckt alle Monitore der gesamten Organisation ab, die diese Tags tragen, unabhängig vom zugehörigen Kunden. Das Erstellen oder Bearbeiten eines organisationsweiten Tag-Fensters erfordert die Rolle **Admin oder Editor**; Readonly-Benutzer erhalten einen Berechtigungsfehler. <Callout type="info"> Die Tag-Abdeckung wird vom Monitoring-Worker live zum Zeitpunkt jedes Check-Ergebnisses ausgewertet, sodass es keine Verzögerung zwischen dem Taggen eines Monitors und seiner Absicherung durch das Fenster gibt. </Callout> ## Einmalig vs. wiederkehrend Ein Fenster ist entweder **einmalig** (Standard) oder **wiederkehrend**. Wiederkehrende Fenster tragen ein Wiederholungsmuster: | Feld | Bedeutung | |------|-----------| | `frequency` | `daily`, `weekly` oder `monthly` | | `interval` | Wiederholung alle *N* Tage/Wochen/Monate (z.B. `2` = jede zweite Woche) | | `daysOfWeek` | Für wöchentlich: welche Tage (`0` = Sonntag … `6` = Samstag) | | `dayOfMonth` | Für monatlich: Tag des Monats (`1`–`31`) | | `endRecurrenceDate` | Optionales Datum, an dem die Wiederholung endet | Die **Start / Ende**-Zeiten definieren die Länge des Fensters innerhalb jeder Wiederholung. ## Auswirkung auf Statusseiten Wenn der Kunde des Ziels eine Statusseite hat: - Ein Ziel mit **aktivem Wartungsfenster** (und ohne offene Vorfälle) wird als **Wartung** angezeigt. - Wartungsfenster können auch in der **Letzten Historie** erscheinen (gesteuert über den Schalter *Letzte Wartungen anzeigen* der Statusseite — siehe [Statusseiten](/status-pages#letzte-historie)). <Callout type="warn"> Wartung überschreibt keine echten Ausfälle: Gibt es während eines Wartungsfensters einen…

## Monitoring

### Monitoring
URL: https://docs.uptimeify.io/de/monitoring
Description: Überwache die Verfügbarkeit und Leistung deiner Websites und Dienste.
Summary: In diesem Bereich findest du Informationen zu allen Monitor-Typen und ihrer Konfiguration. **Website & HTTP:** Uptime, Keyword, Response Time, Page Size, HTTPS Redirect, SSL **Netzwerk & Dienste:** ICMP, SMTP, IMAP/POP, SSH, FTP **DNS & Domain:** DNS, DNSBL, Domain Expiry **Erweitert:** Heartbeat (Cron), Playwright (Synthetischer Browser) Eine vollständige kategorisierte Übersicht findest du unter [Monitoring-Typen](/monitoring/monitoring-types). ## Einstieg - So legst du deinen ersten Monitor an: [Uptime-Monitor einrichten](/monitoring/monitoring-types/uptime) - Für eine Übersicht aller verfügbaren Monitor-Arten siehe: [Monitoring-Typen](/monitoring/monitoring-types) - Wenn du Ausfälle/Probleme im Detail nachverfolgen möchtest: [Incidents](/incidents) - Wenn geplante Arbeiten die Verfügbarkeit beeinflussen dürfen: [Maintenance](/maintenance) - Wenn du Zustände öffentlich darstellen willst: [Status Pages](/status-pages) Für die API-Referenz siehe: - [Monitore API](/de/api/monitors)

### Managed vs. Self-Service Monitore
URL: https://docs.uptimeify.io/de/monitoring/managed-vs-self-service
Description: Jeder Monitor trägt eine Ownership-Klasse, die bestimmt, wer ihn bearbeiten darf und wer seine Alarme erhält.
Summary: Jeder Monitor — Website, DNS, ICMP, SMTP, SSH, FTP, IMAP/POP, Domain-Ablauf und DNSBL — trägt eine **Ownership-Klasse** (`managementType`) mit einem von zwei Werten: - **`managed`** (Standard) — die Organisation betreibt den Monitor im Auftrag des Kunden. Im Kundenportal ist er **schreibgeschützt**; Änderungswünsche laufen über den Change-Request-Flow. Alarme folgen der vollständigen Eskalation der Organisation, inklusive Org-Integrationen (Webhooks, OpsGenie, Org-SMTP). - **`self_service`** — der Kunde besitzt den Monitor. Kunden-Nutzer (auch Portal-Logins mit der Rolle `readonly`) können ihre eigenen Self-Service-Monitore **anlegen, bearbeiten und löschen**, begrenzt durch ein Paket-Kontingent. Alarme gehen **ausschließlich an die Empfänger des Kunden** — Org-Integrationskanäle werden übersprungen. Bestehende Monitore wurden als `managed` klassifiziert — für sie ändert sich nichts, bis du einen Monitor explizit umstellst. ## Wer darf was | Aktion | Kundenportal-Nutzer | Organisations-Admin | |---|---|---| | Monitor ansehen | ✓ (eigener Kunden-Scope) | ✓ | | `self_service`-Monitor bearbeiten/löschen | ✓ (eigene Monitore) | ✓ | | `managed`-Monitor bearbeiten/löschen | ✗ — außer der Kunde hat die `canEditManaged`-Ausnahme | ✓ | | Monitore anlegen | ✓ als `self_service`, sofern erlaubt und im Kontingent | ✓ (jede Klasse) | | Klasse eines Monitors ändern (`managed` ⇄ `self_service`) | ✗ — immer nur die Organisation | ✓ | | Änderung anfragen / Managed-Status anfragen | ✓ (Change Request) | genehmigt/lehnt ab | Kunden können sich niemals selbst Rechte einräumen: Schreibzugriffe eines kunden-gescopten API-Aufrufers auf Berechtigungsfelder werden serverseitig ignoriert, und das Umstellen der Klasse eines Monitors wird mit `403` (`managementTypeOrgOnly`) abgelehnt. ## Berechtigungen und Vererbung Self-Service-Verhalten wird auf zwei Ebenen konfiguriert, mit einem *null-heißt-erben*-Modell: 1. **Paket-Konfiguration** (`PATCH /api/package-configs/:packageType`) setzt die Standards für alle Kunden des Pakets: `allowSelfService` (Standard `false`) und `maxSelfServiceUrls` (Standard `0`), dazu die Kanal-Berechtigungsstandards `enableEmailAlerts`, `enableSmsAlerts`, `enableWebhookAlerts`, `enableIntegrationAlerts`, `enablePostRequestEscalation`. 2. **Kunden-Overrides** (`POST`/`PATCH /api/customers`) können dieselben Felder pro Kunde setzen. `null` (oder das Weglassen des Felds) bedeutet *vom Paket erben*. Das per-Kunde-Flag `canEditManaged` erlaubt einem bestimmten Kunden zusätzlich, `managed`-Monitore zu bearbeiten, ohne sie zu besitzen. Die Auflösung ist immer: Kundenwert → Paket-Standard → Plattform-Standard, und sie fällt geschlossen aus (Abwesenheit = geringste Berechtigung). ## Das Self-Service-Kontingent `maxSelfServiceUrls` begrenzt die **Gesamtzahl** der `self_service`-Monitore eines Kunden **über alle Monitor-Typen hinweg** — fünf Self-Service-Websites plus drei Self-Service-ICMP-Monitore zählen als acht. Ist das Kontingent erreicht, schlägt das Anlegen eines weiteren Self-Service-Monitors (oder das Umstellen eines bestehenden Monitors auf `self_service`) mit `403` (`selfServiceQuotaReached`) fehl. ## Change Requests Bei `managed`-Monitoren zeigt das Portal statt Bearbeitungs-Controls eine **Änderung anfragen**-Aktion. Eine Anfrage hat einen `kind`: - `change` — Freitext-Wunsch („bitte das Check-Intervall erhöhen"). - `request_managed` — der Kunde bittet die Organisation, die Verantwortung für einen Monitor zu übernehmen. Das Annehmen dieser Anfrage stellt den Monitor automatisch auf `managed` um. Anfragen landen im Change-Request-Posteingang der Organisation (**Dashboard → Change Requests**), wo ein Org-Admin sie annimmt oder ablehnt. Offene Anfragen sind auf 10 pro Kunde begrenzt. Die Endpunkte beschreibt die [Change-Requests-API](/de/api/change-requests). ## Was das für die Alarm-Zustellung bedeutet Die Ownership-Klasse steuert das Eskalations-Routing auf Worker-Ebene: - `managed` — unverändert, volle Org-Eskalation (Org-Integ…

### Monitoring-Typen
URL: https://docs.uptimeify.io/de/monitoring/monitoring-types
Description: Uptimeify unterstützt eine breite Palette an Monitor-Typen — von HTTP-Uptime, Keyword- und SSL-Checks über DNS und Netzwerkdienste bis hin zu synthetischen Browser-Abläufen. Wähle den Typ, der zu dem passt, was du überwachen willst.
Summary: ## Website & HTTP <Cards> <Card title="Uptime Monitor" href="/monitoring/monitoring-types/uptime"> HTTP/HTTPS-Verfügbarkeit und Statuscode-Prüfungen für deine Websites. </Card> <Card title="Keyword Monitor" href="/monitoring/monitoring-types/keyword"> Prüft, ob erwarteter Text im Antwort-Body vorhanden ist (oder fehlt). </Card> <Card title="Response Time Check" href="/monitoring/monitoring-types/response-time"> Alarmiert, wenn eine Seite langsamer als dein Schwellenwert antwortet. </Card> <Card title="Page Size Check" href="/monitoring/monitoring-types/page-size"> Verfolgt die Größe der Antwort und erkennt unerwarteten Ballast. </Card> <Card title="HTTPS Redirect Check" href="/monitoring/monitoring-types/https-redirect"> Bestätigt, dass HTTP korrekt auf HTTPS weiterleitet (mit HSTS). </Card> <Card title="SSL Monitor" href="/monitoring/monitoring-types/ssl"> Erkennt ablaufende oder ungültige TLS-Zertifikate rechtzeitig. </Card> </Cards> ## Netzwerk & Dienste <Cards> <Card title="ICMP Monitor" href="/monitoring/monitoring-types/icmp"> Pingt einen Host, um Erreichbarkeit und Paketverlust zu prüfen. </Card> <Card title="SMTP Monitor" href="/monitoring/monitoring-types/smtp"> Prüft, ob Mailserver Verbindungen am SMTP-Port annehmen. </Card> <Card title="IMAP/POP Monitor" href="/monitoring/monitoring-types/imap-pop"> Überwacht Dienste zum Abruf eingehender E-Mails. </Card> <Card title="SSH Monitor" href="/monitoring/monitoring-types/ssh"> Prüft, ob SSH-Endpunkte erreichbar sind und lauschen. </Card> <Card title="FTP Monitor" href="/monitoring/monitoring-types/ftp"> Prüft, ob FTP-Server am konfigurierten Port antworten. </Card> </Cards> ## DNS & Domain <Cards> <Card title="DNS Monitor" href="/monitoring/monitoring-types/dns"> Überwacht A-, AAAA-, MX-, TXT-, CNAME- und weitere Records auf Änderungen. </Card> <Card title="DNSBL Monitoring" href="/monitoring/monitoring-types/dnsbl"> Erkennt, wenn deine IPs auf DNS-Blocklisten landen. </Card> <Card title="Domain Expiry Monitoring" href="/monitoring/monitoring-types/domain-expiry"> Warnt rechtzeitig, bevor eine Domain-Registrierung ausläuft. </Card> </Cards> ## Erweitert <Cards> <Card title="Heartbeat Monitoring (Cron)" href="/monitoring/monitoring-types/heartbeat"> Alarmiert, wenn sich ein geplanter Job nicht mehr meldet. </Card> <Card title="Playwright Monitor" href="/monitoring/monitoring-types/playwright"> Synthetische Browser-Abläufe, die echte Nutzerwege testen. </Card> </Cards>

### DNS-Monitor
URL: https://docs.uptimeify.io/de/monitoring/monitoring-types/dns
Description: Der DNS Monitor prüft in einem festen Intervall die DNS-Antworten für einen Hostnamen (z.B. example.com). Damit können Sie z.B. erkennen, wenn sich A/AAAA Records ändern, MX Records fehlen oder TXT Records (SPF/DMARC/Domain-Verification) unerwartet abweichen.
Summary: ## Funktionsweise - Wir fragen die von Ihnen gewählten **Record-Typen (RRTypes)** ab (z.B. `A`, `AAAA`, `MX`, `TXT`). - Optional vergleichen wir die gefundenen Werte mit Ihren **Expected Values**. - Je nach Trigger-Konfiguration lösen wir einen Incident/Alert aus, z.B. bei: - **Resolve Error** (z.B. `NXDOMAIN`, Timeout) - **Mismatch** (Erwartete Werte stimmen nicht) ## Konfiguration ### Basis-Einstellungen - **Hostname**: Nur der Hostname, ohne Protokoll und Pfad (z.B. `example.com`, nicht `https://example.com/path`). - **Check-Intervall**: Wie oft geprüft werden soll (z.B. 30 Minuten). - **Status**: - `active`: Checks laufen normal. - `maintenance`: Checks laufen weiter, aber Alarme können je nach Alert-Logik gedämpft sein. - `disabled`: Checks laufen nicht. ### DNS-Checks - **RRTypes**: Komma-separierte Liste, z.B. `A, AAAA, MX, TXT`. - **Match Mode**: - `exact`: Werte müssen exakt übereinstimmen. - `contains`: Erwartete Werte müssen in der Antwort enthalten sein. - **Expected Values**: Pro RRType eine Liste erwarteter Werte (mehrere Zeilen). Leere Felder bedeuten „nicht prüfen“. - **Trigger**: - `resolveError`: Alert bei DNS-Resolve-Fehlern. - `mismatch`: Alert bei Abweichungen zu Expected Values. ## Check-Standorte DNS Checks laufen über unsere Monitoring-Standorte. Wenn ein Monitor keine eigenen Einschränkungen hat, gelten (falls vorhanden) die **Customer-Einschränkungen** für erlaubte Länder.

### DNSBL Monitoring
URL: https://docs.uptimeify.io/de/monitoring/monitoring-types/dnsbl
Description: Überwachen Sie die Reputation Ihrer IP-Adressen auf Blacklists.
Summary: <Callout type="warn"> **Status: Lab (Labor)** Dieses Feature befindet sich aktuell in der **Lab-Phase**. Das bedeutet, wir optimieren noch aktiv an Intervallen und der Auswahl der Listen. </Callout> Das DNSBL (DNS-based Blocklist) Monitoring prüft regelmäßig, ob die IP-Adresse Ihres Servers auf einer der bekannten "Schwarzen Listen" (Blocklists/RBLs) geführt wird. Ein Listing auf einer solchen Liste hat oft gravierende Folgen für den E-Mail-Versand (Mails landen im Spam oder werden abgelehnt). ## Funktionsweise Wir nutzen unsere eigene Open-Source-Engine **[uptimeify-dnsbl](https://www.npmjs.com/package/uptimeify-dnsbl)**, um Ihre IP-Adresse gegen über 50 internationale Spam-Datenbanken abzugleichen. ### Prüf-Intervall Aktuell führen wir die Prüfung **alle 180 Minuten (3 Stunden)** durch. - **Grund**: DNSBL-Betreiber blockieren oft zu häufige Abfragen ("Rate Limiting"). Ein 3-Stunden-Rhythmus ist ein guter Kompromiss zwischen Aktualität und "Good Citizenship" gegenüber den Listen-Betreibern. - *Hinweis*: Sollte wirklicher Bedarf für häufigere Checks bestehen, kontaktieren Sie uns gerne. ## Was passiert bei einem Treffer? Wenn wir Ihre IP auf einer Liste finden (z.B. Spamhaus, Barracuda, SORBS): 1. **Benachrichtigung**: Sie erhalten einen Alarm über Ihre konfigurierten Kanäle. 2. **Details**: Wir zeigen Ihnen den spezifischen Grund (z.B. "Listed in SBL" oder "Dynamic IP Range"). 3. **Lösung**: Wir stellen, sofern verfügbar, einen direkten **Delisting-Link** bereit, über den Sie die Austragung beim Listenbetreiber beantragen können. ## Unterstützte Listen Wir fragen eine kuratierte Liste von zuverlässigen Providern ab. Eine vollständige Übersicht finden Sie auf der Seite [Verwendete Listen](/monitoring/monitoring-types/dnsbl/lists). ## Einrichtung DNSBL Monitoring überwacht **IP-Adressen** (z.B. die öffentliche IPv4 Ihres Mailservers). - Legen Sie die zu prüfenden IPs im Admin-Bereich unter **Blacklists** an. - Pro IP können Sie optional einen Anzeigenamen vergeben (z.B. „Mailserver IPv4“). - IPs können deaktiviert werden, ohne sie zu löschen (z.B. bei Migration). ## Benachrichtigungen Es gibt zwei Ereignisse: - **Listing erkannt**: Ihre IP ist auf mindestens einer Liste geführt. - **Delisting erkannt**: Ihre IP ist wieder „clean“. Zusätzlich können (je nach Konfiguration) **Erinnerungen** gesendet werden, wenn eine IP über längere Zeit gelistet bleibt. Wichtig: DNSBL Monitoring ist ein **Warning-only Monitor**. Es werden **keine Downtime-Incidents** erzeugt, da es sich um ein Reputations-/Zustandssignal handelt (und nicht um eine Erreichbarkeitsprüfung). ## Welche Details werden angezeigt? Wenn ein Listing erkannt wurde, zeigen wir – sofern vom Listenbetreiber verfügbar – unter anderem: - Name/Key der Liste - Grund/„Reason“ (falls vorhanden) - **Delisting-Link** (falls vorhanden) Außerdem sehen Sie den letzten Prüfzeitpunkt sowie ggf. eine letzte Fehlermeldung, falls einzelne DNS-Abfragen temporär fehlgeschlagen sind. ## Troubleshooting ### „Unbekannt“ / keine aktuellen Daten Wenn noch keine Prüfung gelaufen ist oder die IP gerade erst angelegt wurde, kann der Status zunächst als „unbekannt“ erscheinen. Warten Sie einen Prüfzyklus ab. ### Teilweise DNS-Fehler DNSBL-Anbieter reagieren sensibel auf hohe Query-Raten. Wenn einzelne Listen temporär mit Fehlern (z.B. Rate Limit/Servfail) antworten, wird das als Hinweis gespeichert. Wichtig: Wenn Ihre IP **zuvor gelistet** war, wechseln wir bei degradierten/teilweisen Daten **nicht vorschnell** auf „clean“.

### Verwendete RBL Listen
URL: https://docs.uptimeify.io/de/monitoring/monitoring-types/dnsbl/lists
Description: Wir überwachen Ihre IP-Adressen derzeit gegen die folgenden Listen. Diese Auswahl deckt die wichtigsten und zuverlässigsten internationalen Anti-Spam-Datenbanken ab.
Summary: Wir nutzen hierfür **[uptimeify-dnsbl](https://www.npmjs.com/package/uptimeify-dnsbl)**. ## Spamhaus Project *Die wohl wichtigste RBL weltweit.* - Spamhaus ## Weitere wichtige Listen - Barracuda (BRBL) - SpamCop - SORBS (Aggregate) - UCEPROTECT (Level 1, 2) - Hostkarma - Backscatterer - Invaluement SIP - SpamCannibal - DroneBL - Spam Eating Monkey (SEM-BLACK) - URIBL Black - RV-SOFT Technology - ZapBL - Suomispam Reputation - Kempt.net - Korea Services - NiX Spam - Passive Spam Block List (PSBL) - InterServer RBL - all.s5h.net - Abuse.ch (Combined, Drone, Spam) - 0spam (RBL, Blocklist) - Singular TTK PTE - SpamRats (Spam, Dyna, NoPtr) - Spamsources Fabel - Virus RBL JP - Woody's SMTP Blacklist - WPBL - Gweep (Proxy, Relays) - Digibase Spambot - Lashback UBL - WormRBL - Team Cymru Bogons - Nether.net Relays - Imp.ch Spam RBL - Mailspike Z - Anonmails.de - Pedantic.org - GBUdb Truncate ## Hinweise zur Nutzung Wir führen die Queries "Aggregated" durch. Das bedeutet, wir fragen nicht jede Liste einzeln nacheinander ab, sondern parallelisiert und optimiert, um die Antwortzeit gering zu halten und Timeouts zu vermeiden.

### Domain-Ablauf-Überwachung
URL: https://docs.uptimeify.io/de/monitoring/monitoring-types/domain-expiry
Description: Eine abgelaufene Domain ist einer der schwerwiegendsten Vorfälle, die einer Website passieren können. Sobald eine Domain abläuft, ist die gesamte Online-Präsenz unerreichbar — und im schlimmsten Fall wird die Domain von einem Dritten registriert. Unser Domain Expiry Monitoring hilft Ihnen, dies proaktiv zu verhindern.
Summary: ## Funktionsweise Wir verwenden das **RDAP-Protokoll** (Registration Data Access Protocol) — den modernen Nachfolger von WHOIS — um die Registrierungsdaten Ihrer Domains direkt bei den zuständigen Registries abzufragen. RDAP liefert strukturierte, zuverlässige Daten und wird von allen großen TLDs unterstützt. ### Prüf-Intervall Aktuell führen wir die Prüfung **alle 12 Stunden** durch (konfigurierbar per Umgebungsvariable). - **Grund**: Domain-Registrierungsdaten ändern sich selten. Ein 12-Stunden-Rhythmus bietet rechtzeitige Erkennung und bleibt gleichzeitig respektvoll gegenüber den Rate-Limits der Registries. - *Hinweis*: Sollte wirklicher Bedarf für häufigere Checks bestehen, kontaktieren Sie uns gerne. ## Zwei Überwachungswege Das Domain Expiry Monitoring arbeitet über zwei unabhängige Kanäle: ### 1. Website-basierte Prüfungen Wenn der **Domain Expiry Check** für eine Website aktiviert ist, extrahieren wir automatisch die Domain aus der URL und prüfen deren Ablaufdatum. Ergebnisse werden zusammen mit den regulären Monitoring-Daten gespeichert. ### 2. Registrierte Kunden-Domains Domains können auch unabhängig im Bereich **Admin → Domains** registriert werden. Das ist nützlich für: - Domains, die nicht aktiv als Websites überwacht werden (z.B. geparkte Domains, Mail-only-Domains). - Tracking von Domains mit individuellen Warnschwellen pro Domain. - Domain-spezifische Benachrichtigungs-Overrides (separate E-Mail-/Telefon-Kontakte). ## Schwellenwerte Zwei konfigurierbare Schwellenwerte bestimmen, wann Alarme ausgelöst werden: | Schwellenwert | Standard | Zweck | |---|---|---| | **Warnung** | 30 Tage | Frühzeitiger Hinweis, dass eine Verlängerung ansteht. | | **Kritisch** | 7 Tage | Dringender Alarm — Domain läuft in wenigen Tagen ab. | Diese Schwellenwerte können individuell pro Website oder pro registrierter Domain konfiguriert werden. ## Was passiert bei einer Schwellenwert-Überschreitung? 1. **Warnung**: Sie erhalten einen Alarm über Ihre konfigurierten Benachrichtigungskanäle, sobald die Domain das Warnfenster erreicht. 2. **Kritisch**: Ein dringender Alarm wird ausgelöst, wenn die Domain innerhalb des kritischen Schwellenwerts abläuft. 3. **Abgelaufen**: Ist die Domain bereits abgelaufen, markieren wir sie sofort. 4. **Wiederherstellung**: Wird eine Domain verlängert und befindet sich nicht mehr im Warnfenster, werden offene Vorfälle automatisch aufgelöst und eine Wiederherstellungsbenachrichtigung versendet. ## Überwachte Daten Für jede Domain erfassen und zeigen wir: - **Ablaufdatum**: Wann die Domain-Registrierung abläuft. - **Registrar**: Welcher Registrar die Domain verwaltet (z.B. „INWX", „Hetzner", „GoDaddy"). - **Tage bis zum Ablauf**: In Echtzeit berechnet. - **Aktueller Status**: OK, Warnung, Kritisch oder Abgelaufen. - **Letzte Prüfung**: Zeitstempel der letzten RDAP-Abfrage. ## Unterstützte TLDs RDAP wird von allen großen gTLDs (.com, .net, .org usw.) und vielen ccTLDs (.de, .at, .ch, .nl, .uk usw.) unterstützt. Wird eine TLD nicht von RDAP unterstützt, überspringen wir die Prüfung lautlos — es werden keine Fehlalarme erzeugt. ## Fehlerbehebung Wenn wir ein Domain-Ablauf-Problem melden: 1. Prüfen Sie bei Ihrem Registrar, ob die Domain auf **Auto-Renew** gestellt ist. 2. Stellen Sie sicher, dass die hinterlegte Zahlungsmethode bei Ihrem Registrar noch gültig ist. 3. Bei Domains, die von Dritten verwaltet werden — bestätigen Sie, dass die zuständige Person über die anstehende Verlängerung informiert ist.

### FTP-Monitor
URL: https://docs.uptimeify.io/de/monitoring/monitoring-types/ftp
Description: Der FTP Monitor prüft, ob Ihr FTP-Service erreichbar und responsiv ist. Damit erkennen Sie Ausfälle bei File-Transfer-Infrastruktur, z.B. für Legacy-Integrationen, Batch-Exports oder Partner-Uploads.
Summary: ## Funktionsweise - Wir verbinden uns mit Ihrem FTP-Endpunkt und prüfen, ob der Dienst antwortet. - Ist der Server nicht erreichbar oder antwortet nicht innerhalb des Timeouts, schlägt der Check fehl. ## Konfiguration ### Basis-Einstellungen - **Hostname**: Nur Hostname, ohne Protokoll und ohne Pfad. - **Port**: Optional (Standard ist typischerweise 21). - **Check-Intervall** und **Timeout**. - **Status**: `active`, `maintenance`, `disabled`. ### Erweiterte Einstellungen Wenn Ihr Server Authentifizierung oder Verschlüsselung (z.B. FTPS) benötigt, können diese Optionen in den Monitor-Einstellungen konfiguriert werden. ### Monitoring-Standorte FTP Checks laufen von unseren Monitoring-Standorten. Monitor-level **Allowed Check Countries** (oder kundenspezifische Defaults) steuern die verwendeten Standorte.

### Heartbeat-Überwachung (Cron)
URL: https://docs.uptimeify.io/de/monitoring/monitoring-types/heartbeat
Description: Heartbeat Monitoring (auch bekannt als Cron Monitoring) funktioniert andersherum: Anstatt dass wir Ihre Server prüfen, benachrichtigt Ihr Server (oder Skript) uns, dass er lebt.
Summary: Dies ist perfekt für die Überwachung von: - **Täglichen Backups:** Stellen Sie sicher, dass Ihre Datenbank-Backups tatsächlich gelaufen sind. - **Hintergrund-Jobs:** Überwachen Sie Worker, Import-Skripte oder periodische Aufgaben. - **Intranet-Geräten:** Überwachen Sie Geräte hinter einer Firewall, die ausgehende Anfragen senden können. ## Funktionsweise 1. Sie erstellen einen **Heartbeat Monitor** im Dashboard. 2. Wir geben Ihnen eine eindeutige **Heartbeat URL**. 3. Sie konfigurieren Ihr Skript (Cronjob, Worker), diese URL aufzurufen, wenn es erfolgreich beendet wurde. 4. Wir erwarten einen Ping innerhalb Ihres konfigurierten **Intervalls** (plus einer **Grace Period**). 5. Wenn wir keinen Ping rechtzeitig erhalten, senden wir einen Alarm: "Heartbeat missing". ## Konfiguration ### Erwartetes Intervall (Expected Interval) Wie oft erwarten Sie den Ping? - *Beispiel:* Für ein tägliches Backup setzen Sie dies auf **24 Stunden** (1440 Minuten). - *Beispiel:* Für einen minütlichen Worker setzen Sie dies auf **1 Minute**. ### Grace Period (Toleranzzeit) Wie viel Verzögerung ist akzeptabel? - *Beispiel:* Wenn Ihr Backup normalerweise 10 Minuten dauert, aber manchmal 30, setzen Sie die Grace Period auf **30 Minuten**. - Wir alarmieren nur, wenn `Letzter Ping + Intervall + Grace Period < JETZT`. ## Anwendungsbeispiele ### Linux Cronjob (Backup Script) ```bash #!/bin/bash # Backup ausführen ... pg_dump dbname > backup.sql # Wenn erfolgreich, Heartbeat pingen if [ $? -eq 0 ]; then curl -m 10 --retry 3 https://ping.uptimeify.io/ping/YOUR_TOKEN fi ``` ### PowerShell (Windows) ```powershell # Task ausführen... Write-Output "Task running..." # Heartbeat pingen Invoke-RestMethod -Uri "https://ping.uptimeify.io/ping/YOUR_TOKEN" ``` ### Node.js Worker ```javascript await doImport(); # Ping await fetch('https://ping.uptimeify.io/ping/YOUR_TOKEN'); ```

### HTTPS-Weiterleitungs-Check
URL: https://docs.uptimeify.io/de/monitoring/monitoring-types/https-redirect
Description: Sicherheit und SEO sind heute unverzichtbar. Der HTTPS Redirect Check stellt sicher, dass Besucher, die Ihre Website unverschlüsselt via http:// aufrufen, automatisch auf die sichere https:// Version weitergeleitet werden.
Summary: ## Warum ist das wichtig? - **Sicherheit**: Verhindert Man-in-the-Middle-Angriffe. - **SEO**: Suchmaschinen wie Google bevorzugen HTTPS und bestrafen Seiten ohne korrekte Weiterleitung. - **User Trust**: Nutzer sehen das Schloss-Symbol im Browser. ## Funktionsweise Dieser Check ist eine Option innerhalb des Uptime Monitors. Wenn aktiviert: 1. Wir rufen die URL explizit mit `http://` auf. 2. Wir erwarten einen Status Code `301` (Permanent Redirect) oder `302` (Found) sowie `307/308`. 3. Wir prüfen, ob das Ziel der Weiterleitung mit `https://` beginnt. ## Konfiguration Sie finden diese Einstellung in den erweiterten Optionen Ihres Monitors: - **Enable HTTPS Redirect Check**: Aktivieren Sie diese Option, um die Weiterleitung zu erzwingen.

### ICMP-Monitor
URL: https://docs.uptimeify.io/de/monitoring/monitoring-types/icmp
Description: Der ICMP Monitor prüft, ob ein Host im Netzwerk erreichbar ist. Das ist ideal für Infrastruktur-Komponenten, die keinen HTTP-Endpunkt anbieten (z.B. Router, Firewalls, VPN-Gateways, Datenbanken oder interne Services).
Summary: ## Funktionsweise - Wir senden ICMP Echo Requests („Ping“) an den konfigurierten **Hostname**. - Der Monitor gilt als gesund, wenn das Ziel innerhalb des Timeouts antwortet. - Wir erfassen Latenz und erkennen anhaltende Erreichbarkeitsprobleme. ## Konfiguration ### Basis-Einstellungen - **Name**: Verständlicher Anzeigename. - **Hostname**: Hostname oder IP-Adresse (ohne Protokoll, ohne Pfad). - **Check-Intervall**: Wie oft geprüft wird. - **Timeout**: Wie lange wir auf eine Antwort warten. - **Status**: - `active`: Checks laufen normal. - `maintenance`: Checks laufen weiter, aber Alerting kann je nach Logik reduziert sein. - `disabled`: Checks laufen nicht. ### Monitoring-Standorte ICMP Checks laufen von unseren Monitoring-Standorten. - Wenn Sie **Allowed Check Countries** am Monitor setzen, laufen Checks nur aus passenden Ländern. - Wenn der Monitor keine Einschränkung hat, gelten (falls konfiguriert) die **kundenspezifischen Allowed Countries**.

### IMAP/POP-Monitor
URL: https://docs.uptimeify.io/de/monitoring/monitoring-types/imap-pop
Description: Der IMAP/POP Monitor verifiziert, dass Ihr Mail-Server für Clients erreichbar ist. Damit lassen sich Konnektivitäts- und Authentifizierungsprobleme erkennen, die den Inbox-Zugriff beeinträchtigen.
Summary: ## Funktionsweise - Wir verbinden uns mit Ihrem IMAP- oder POP-Endpunkt und prüfen, ob der Dienst antwortet. - Ist der Server nicht erreichbar oder antwortet nicht rechtzeitig, schlägt der Check fehl. ## Konfiguration ### Basis-Einstellungen - **Hostname**: Nur Hostname, ohne Protokoll und ohne Pfad. - **Port**: Optional (häufig 143/993 für IMAP, 110/995 für POP). - **Check-Intervall** und **Timeout**. - **Status**: `active`, `maintenance`, `disabled`. ### Erweiterte Einstellungen Protokoll-Auswahl (IMAP vs POP) und weitere Optionen (z.B. Verschlüsselung/Authentifizierung) können in den Monitor-Einstellungen konfiguriert werden. ### Monitoring-Standorte IMAP/POP Checks laufen von unseren Monitoring-Standorten. Sie können die Ausführung über **Allowed Check Countries** (Monitor-Ebene) oder kundenspezifische Defaults begrenzen.

### Keyword-Monitor
URL: https://docs.uptimeify.io/de/monitoring/monitoring-types/keyword
Description: Manchmal ist eine Seite technisch \\\"online\\\" (Status Code 200), zeigt aber nicht den gewünschten Inhalt an – zum Beispiel eine weiße Seite, eine Fehlerdatenbank-Meldung oder \\\"Out of Stock\\\". Der Keyword Monitor (auch \\\"Content Monitor\\\" genannt) löst dieses Problem.
Summary: ## Funktionsweise Der Keyword Monitor lädt den HTML-Body Ihrer Seite und durchsucht ihn nach einem bestimmten Text (String). Er ist nützlich, um sicherzustellen, dass: - Die Datenbankverbindung steht (Prüfung auf dynamische Inhalte). - Das CMS korrekt rendert. - Kein Wartungsmodus angezeigt wird. ## Konfigurations-Modi Sie können den Monitor in zwei Modi betreiben: ### 1. "Muss enthalten sein" (Keyword Present) Alarm, wenn das Wort **NICHT** gefunden wird. - **Use Case**: Prüfen Sie auf "Willkommen", "Impressum" oder den Firmennamen im Footer. - **Beispiel**: Auf einer Shop-Seite prüfen Sie auf den Namen eines Bestseller-Produkts. ### 2. "Darf nicht enthalten sein" (Keyword Absent) Alarm, wenn das Wort **GEFUNDEN** wird. - **Use Case**: Prüfen auf Fehlermeldungen. - **Beispiele**: "MySQL Error", "404 Not Found" (im Text), "Hacked by", "Maintenance Mode". ## Einrichtungsschritte 1. Erstellen Sie einen neuen Monitor oder bearbeiten Sie einen bestehenden. 2. Wählen Sie unter "Erweiterte Einstellungen" die Option **Keyword Check**. 3. Geben Sie den Suchbegriff ein (Case-sensitive beachten!). 4. Speichern Sie den Monitor.

### Seitengrößen-Check
URL: https://docs.uptimeify.io/de/monitoring/monitoring-types/page-size
Description: Der Page Size Check überwacht die Größe des HTML-Antwortinhalts (Body) Ihrer Website in Bytes. Unerwartete Änderungen an der Dateigröße können auf ernste Probleme hinweisen, die vom reinen Status-Code-Check (200 OK) übersehen werden.
Summary: ## Anwendungsfälle - **Hacks / Defacements**: Angreifer injizieren oft Code, was die Seite signifikant vergrößert. - **Leere Seiten**: Ein Datenbank-Fehler könnte dazu führen, dass nur der Header gerendert wird (Seite plötzlich sehr klein), obwohl der Server Status 200 meldet. - **Performance**: Versehentlich eingebundene riesige Skripte oder CSS-Dateien im HTML. ## Konfiguration Sie können Schwellenwerte definieren: ### Minimale Größe (Min Page Size) Alarm, wenn die Seite kleiner als X Bytes ist. - *Empfehlung*: Setzen Sie dies auf ca. 80-90% der normalen Größe Ihrer Seite, um teils leere Renderings zu erkennen. ### Maximale Größe (Max Page Size) Alarm, wenn die Seite größer als Y Bytes ist. - *Empfehlung*: Schützt vor "Code bloat" oder Injections. Der Check gilt als fehlgeschlagen, wenn die tatsächliche Größe außerhalb dieses Bereichs liegt.

### Playwright-Monitor
URL: https://docs.uptimeify.io/de/monitoring/monitoring-types/playwright
Description: Für kritische Prozesse wie Login, Checkout oder Registrierung reicht ein einfacher HTTP-Check oft nicht aus. Der Playwright Monitor lädt Ihre Website in einem echten Browser (Headless Chromium) und führt ein von Ihnen definiertes Skript aus.
Summary: Dies simuliert einen echten Benutzer und deckt JavaScript-Fehler, defekte Buttons oder UI-Probleme auf. ## Funktionsweise Wir führen Ihr Playwright-Skript in unserer sicheren Cloud-Umgebung aus. - **Erfolg**: Das Skript läuft ohne Fehler durch. - **Fehler**: Eine `expect`-Prüfung schlägt fehl oder ein Timeout tritt auf. Wir speichern automatisch einen **Screenshot** und die Fehlermeldung. ## Beispiel: Login Testen Hier ist ein einfaches Skript, um einen Login-Vorgang zu testen: ```javascript test('User can login', async ({ page }) => { // 1. Navigation await page.goto('https://app.example.com/login'); // 2. Formular ausfüllen (Nutzung von Env-Variablen) await page.fill('input[name="email"]', 'monitor-user@example.com'); await page.fill('input[name="password"]', process.env.MONITOR_PASSWORD); // 3. Absenden await page.click('button[type="submit"]'); // 4. Verifizierung (Warten auf Dashboard-Element) await expect(page).toHaveURL(/dashboard/); await expect(page.locator('.welcome-message')).toContainText('Hallo'); }); ``` ## Umgebungsvariablen (Secrets) Sie sollten niemals Passwörter, API-Keys oder sensible Daten direkt im Skript speichern ("hardcoden"). Nutzen Sie stattdessen **Environment Variables**. ### Einrichtung 1. Navigieren Sie zu den **Monitor-Einstellungen**. 2. Öffnen Sie den Bereich **Erweiterte Einstellungen** (Advanced Settings). 3. Finden Sie den Abschnitt **Environment Variables**. 4. Tragen Sie Schlüssel (Key) und Wert (Value) ein. - Beispiel Key: `PASSWORD` - Beispiel Value: `GeheimesPasswort123!` ### Verwendung im Skript Im Playwright-Code greifen Sie über `process.env.KEY` auf die Werte zu. Die Werte werden erst zur Laufzeit in der sicheren Worker-Umgebung injiziert. ```javascript test('Secure Login', async ({ page }) => { await page.goto('https://example.com/login'); // Sicherer Zugriff via process.env await page.fill('#password', process.env.PASSWORD); await page.click('#submit'); }); ``` ### Sicherheit - Die Werte werden **verschlüsselt** in unserer Datenbank gespeichert. - Sie sind im Frontend-Editor nach dem Speichern nicht mehr im Klartext einsehbar (je nach Berechtigung). - Sie tauchen nicht im Screenshot-Log auf (sofern Sie sie nicht explizit `console.log`gen). ## Tipps für stabile Tests - Nutzen Sie `data-testid` Attribute für Selektoren, wo möglich. - Warten Sie auf Elemente (`expect(locator).toBeVisible()`) statt feste `sleep()` Zeiten zu nutzen. - Halten Sie die Szenarien kurz und fokussiert (z.B. nur "Login" statt "Login + Kauf + Logout").

### Antwortzeit-Check
URL: https://docs.uptimeify.io/de/monitoring/monitoring-types/response-time
Description: Neben der reinen Erreichbarkeit ist die Geschwindigkeit entscheidend für die Nutzererfahrung. Der Response Time Check misst, wie lange Ihr Server benötigt, um auf eine Anfrage zu antworten.
Summary: ## Was wird gemessen? Wir messen typischerweise die **Time to First Byte (TTFB)** sowie die Zeit für den vollständigen Transfer des HTML-Dokuments. ## Konfiguration Sie können Schwellenwerte für Warnungen festlegen: - **Threshold (ms)**: Wenn die Antwortzeit diesen Wert überschreitet (z.B. 2000ms), wird, je nach Konfiguration, ein Alarm ausgelöst oder der Status als "Degraded" markiert. ## Analyse In den Monitor-Details finden Sie Diagramme zur zeitlichen Entwicklung der Antwortzeit. Dies hilft Ihnen: - Performance-Engpässe zu bestimmten Uhrzeiten zu erkennen (z.B. während Backups). - Die Auswirkungen von Code-Deployments auf die Geschwindigkeit zu sehen.

### SMTP-Monitor
URL: https://docs.uptimeify.io/de/monitoring/monitoring-types/smtp
Description: Der SMTP Monitor verifiziert, dass Ihr SMTP-Server erreichbar und responsiv ist. So erkennen Sie Ausfälle bei Mail-Gateways oder Outbound-Mail frühzeitig.
Summary: ## Funktionsweise - Wir verbinden uns mit Ihrem SMTP-Server und prüfen, ob er erwartungsgemäß antwortet. - Ist der Server nicht erreichbar oder antwortet nicht rechtzeitig, schlägt der Check fehl. ## Konfiguration ### Basis-Einstellungen - **Hostname**: Nur Hostname, ohne Protokoll und ohne Pfad. - **Port**: Optional. Verwenden Sie Ihren SMTP-Port (häufig 25 / 587 / 465). - **Check-Intervall** und **Timeout**. - **Status**: `active`, `maintenance`, `disabled`. ### Erweiterte Einstellungen Je nach Anwendungsfall können erweiterte Optionen (z.B. Verschlüsselung/Authentifizierung) in den Monitor-Einstellungen konfiguriert werden. ### Monitoring-Standorte SMTP Checks laufen von unseren Monitoring-Standorten. Mit **Allowed Check Countries** (Monitor-Ebene) oder kundenspezifischen Defaults steuern Sie, von wo geprüft wird.

### SSH-Monitor
URL: https://docs.uptimeify.io/de/monitoring/monitoring-types/ssh
Description: Der SSH Monitor prüft, ob Ihr SSH-Service erreichbar ist. Typische Anwendungsfälle sind Firewall-Probleme, Netzwerkstörungen oder Server-Ausfälle, bei denen der Admin-Zugriff nicht mehr möglich ist.
Summary: ## Funktionsweise - Wir versuchen, eine Verbindung zu Ihrem SSH-Service aufzubauen. - Ist der Server nicht erreichbar, lehnt Verbindungen unerwartet ab oder läuft in ein Timeout, schlägt der Check fehl. ## Konfiguration ### Basis-Einstellungen - **Hostname**: Hostname oder IP-Adresse. - **Port**: Optional (Standard ist typischerweise 22). - **Check-Intervall** und **Timeout**. - **Status**: `active`, `maintenance`, `disabled`. ### Monitoring-Standorte SSH Checks laufen von unseren Monitoring-Standorten. Nutzen Sie **Allowed Check Countries**, um die Ausführungsorte zu begrenzen.

### SSL-Monitor
URL: https://docs.uptimeify.io/de/monitoring/monitoring-types/ssl
Description: Abgelaufene SSL-Zertifikate sind eine häufige Ursache für Ausfälle und Vertrauensverlust bei Nutzern. Browser zeigen dann Warnmeldungen wie \\\"Verbindung nicht sicher\\\" an. Unser SSL Monitor hilft Ihnen, dies proaktiv zu verhindern.
Summary: ## Funktionsweise Der SSL Monitor prüft regelmäßig die Konfiguration Ihres TLS/SSL-Zertifikats. Er ist oft in den Uptime Monitor integriert, kann aber auch separat konfiguriert werden. ## Überwachte Metriken ### 1. Ablaufdatum (Expiry) Dies ist die wichtigste Prüfung. Wir alarmieren Sie rechtzeitig vor dem Ablaufdatum, damit Sie das Zertifikat erneuern können. - **Benachrichtigung**: Standardmäßig erinnern wir Sie **30, 14, 7 und 1 Tag(e)** vor Ablauf (konfigurierbar). ### 2. Gültigkeit & Chain of Trust Wir prüfen, ob das Zertifikat: - Von einer vertrauenswürdigen Root-CA signiert ist. - Nicht widerrufen wurde (OCSP/CRL Check). - Für den korrekten Hostnamen (Domain) ausgestellt ist. ## Fehlerbehebung Wenn wir einen SSL-Fehler melden: 1. Prüfen Sie das Ablaufdatum. 2. Prüfen Sie, ob die "Intermediate Certificates" korrekt installiert sind (Chain incomplete Fehler). 3. Stellen Sie sicher, dass der Hostname im Zertifikat (CN oder SAN) mit der überwachten URL übereinstimmt.

### Uptime-Monitor
URL: https://docs.uptimeify.io/de/monitoring/monitoring-types/uptime
Description: Der Uptime Monitor ist das Herzstück Ihrer Überwachung. Er prüft regelmäßig, ob Ihre Website oder Ihr API-Endpunkt für Ihre Kunden erreichbar ist. Wir empfehlen, für jede öffentlich zugängliche Seite mindestens einen Uptime Monitor einzurichten.
Summary: ## Funktionsweise Wir senden in dem von Ihnen gewählten Intervall (z.B. alle 30 Sekunden oder jede Minute) HTTP- oder HTTPS-Anfragen an Ihre URL. Wir werten den Monitor als "Online", wenn: 1. Der Server antwortet (kein Timeout). 2. Der **Status Code** den Erwartungen entspricht (standardmäßig `2xx`, z.B. 200 OK). Wenn ein Fehler erkannt wird, verifizieren wir diesen von mehreren Standorten weltweit, um Fehlalarme zu vermeiden, bevor wir eine Benachrichtigung senden. ## Website anlegen ### Wo finde ich das im UI? Im Dashboard unter **Websites** → **Neue Website** / **Create Website**. ### Name Gib der Website einen Namen, der im Team eindeutig ist (z.B. „Marketing Website", „Shop API", „Kundenportal"). ### URL <Callout type="info"> Uptimeify **ergänzt `https://` automatisch**, wenn du nur einen Hostnamen eingibst (z.B. `example.com`). Du musst das Protokoll also nicht selbst eingeben — du kannst aber auch die vollständige URL (z.B. `https://example.com`) einfügen. </Callout> Tipps: - Trage nach Möglichkeit direkt die kanonische Ziel-URL ein (meist `https://…`). - Wenn du HTTP→HTTPS-Weiterleitungen prüfen willst, nutze zusätzlich den Monitor-Typ **HTTPS Redirect**. ### Status Du kannst eine Website aktiv lassen oder temporär deaktivieren (z.B. bei Migrationen). Ein deaktivierter Eintrag wird nicht überwacht. ## Konfiguration ### Basis-Einstellungen - **URL**: Die vollständige Adresse (z.B. `https://example.com`). - **Check-Intervall**: Wie oft geprüft werden soll (z.B. 60s). ### Fortgeschrittene Einstellungen - **Erwartete Status Codes**: Standardmäßig prüfen wir auf `200-299`. Sie können dies anpassen, z.B. auf `200,301,302`, wenn Weiterleitungen als "Erfolg" gelten sollen. - **Timeout**: Wie lange wir maximal auf eine Antwort warten (Standard: 30s). - **HTTP-Methode**: Standardmäßig `GET`. Sie können auch `HEAD`, `POST` usw. wählen. - **Request Body & Headers**: Senden Sie JSON-Daten oder Authentifizierungs-Token mit (z.B. `Authorization: Bearer ...`). ## Optionale Checks Beim Einrichten eines Uptime Monitors kannst du zusätzliche Checks neben der reinen Erreichbarkeitsprüfung aktivieren: - **SSL**: Zertifikatsgültigkeit und Ablaufdatum überwachen → siehe [SSL Monitor](/monitoring/monitoring-types/ssl) - **Response Time**: Performance-Schwellenwerte setzen und bei Verlangsamungen benachrichtigt werden (siehe [Antwortzeit](#antwortzeit-response-time) unten) - **Keyword / Content Validation**: Prüfen, ob bestimmte Inhalte in der Antwort vorhanden sind - **Page Size**: Warnung bei unerwarteten Größenänderungen, die auf fehlende Ressourcen oder übermäßiges Volumen hinweisen ## Häufige Stolpersteine ### URL vs. Hostname (DNS/ICMP) Der Uptime Monitor akzeptiert einen reinen Hostnamen (Uptimeify ergänzt `https://` automatisch) oder eine vollständige URL. Manche anderen Monitor-Typen arbeiten dagegen mit einem **Hostname ohne Protokoll** und senden keine HTTP-Anfragen. - DNS Monitor: Hostname ohne Protokoll (z.B. `example.com`) → siehe [DNS Monitor](/monitoring/monitoring-types/dns) - ICMP Monitor: Hostname ohne Protokoll (z.B. `server.example.com`) → siehe [ICMP Monitor](/monitoring/monitoring-types/icmp) ### Authentifizierung / Bot-Protection Wenn deine Seite z.B. Basic Auth, Token-Auth oder eine Bot-Protection nutzt, kann ein klassischer HTTP-Check fehlschlagen. - Konfiguriere Auth-Header/Basic Auth im Feld **Request Headers**. - Für komplexe Login-Flows ist **Playwright** oft die robustere Wahl. ## Antwortzeit (Response Time) Neben dem Status speichern wir auch die Antwortzeit (Time to First Byte + Download). - Sie können Alarme konfigurieren, wenn die Antwortzeit einen Schwellenwert überschreitet (z.B. > 2000ms), auch wenn der Status 200 OK ist. ## Nächste Schritte - Ausfälle nachverfolgen und Verlauf ansehen: [Incidents](/incidents)

### Tags verwenden
URL: https://docs.uptimeify.io/de/monitoring/tags
Description: Monitore mit farbigen Tags organisieren und filtern — für alle Monitor-Typen.
Summary: Tags ermöglichen es dir, jeden Monitor — Website, DNS, ICMP, SMTP, SSH, FTP oder IMAP/POP — mit einem oder mehreren farbigen Badges zu versehen. Anschließend kannst du jede Monitor-Liste nach Tag filtern und sofort sehen, welche Monitore zu einer Gruppe gehören (z. B. „Produktion", „Kunde A", „Staging"). ## Tags erstellen Öffne **Einstellungen → Tags** und klicke auf **Neuer Tag**. Gib an: - **Name** — eine kurze Bezeichnung, bis zu 50 Zeichen. - **Farbe** — wähle aus der festen Palette: `slate`, `red`, `amber`, `green`, `teal`, `blue`, `indigo`, `violet`, `pink` oder `gray`. Tags sind auf die Organisation beschränkt: Alle Mitglieder mit ausreichenden Rechten können sie sehen und verwenden. ### Regel für Readonly-Mitglieder Readonly-Mitglieder **können** Tags erstellen, aber diese Tags sind nur für sie selbst sichtbar. Ein Readonly-Mitglied kann Tags anderer Nutzer weder sehen, noch bearbeiten oder löschen. Sie können eigene Tags jedem Monitor zuweisen, auf den sie Lesezugriff haben. ## Farbpalette | Schlüssel | Farbe | |-----------|-------| | `slate` | Slate / Neutralgrau | | `red` | Rot | | `amber` | Amber / Orange | | `green` | Grün | | `teal` | Türkis | | `blue` | Blau | | `indigo` | Indigo | | `violet` | Violett / Lila | | `pink` | Pink | | `gray` | Grau | ## Tags zuweisen Tags können an zwei Stellen zugewiesen werden: ### Aus der Monitor-Liste (inline) Suche in einer beliebigen Monitor-Liste (Websites, DNS, ICMP usw.) die Spalte **Tags**. Klicke auf den Tag-Bereich einer Zeile, um den Tag-Picker zu öffnen und Tags für diesen Monitor ein- oder auszuschalten. ### Über die Monitor-Detailseite Öffne die Detailseite eines Monitors und suche den Abschnitt **Tags**. Verwende den Tag-Picker, um Tags hinzuzufügen oder zu entfernen. Änderungen werden sofort gespeichert. ## Die Tags-Spalte Die Tags-Spalte erscheint standardmäßig in jeder Monitor-Liste. Für eine kompaktere Ansicht kannst du die Spalte über das Menü **Spalten** oben in der Liste ausblenden. Deine Einstellung wird pro Liste gespeichert. ## Nach Tag filtern Öffne oben in einer beliebigen Monitor-Liste das **Filter**-Menü und wähle einen oder mehrere Tags aus. Die Liste zeigt dann nur noch Monitore, die **alle** gewählten Tags tragen (UND-Logik). Um den Filter zu löschen, entferne alle Tags oder klicke auf **Filter zurücksetzen**. ## Tags verwalten Gehe zu **Einstellungen → Tags**, um die vollständige Tag-Liste zu sehen. Von dort kannst du: - **Bearbeiten** — Name oder Farbe eines Tags ändern (nur Ersteller oder Admin). - **Löschen** — ein Tag entfernen; dadurch wird er von allen Monitoren entfernt, denen er zugewiesen war (Kaskadenlöschung). ## API-Referenz Siehe den Abschnitt [Tags API](../api/tags) für programmatischen Zugriff auf Erstellen, Aktualisieren, Löschen und Zuweisen von Tags.

## Status Pages

### Statusseiten
URL: https://docs.uptimeify.io/de/status-pages
Description: Mit Statusseiten kommunizieren Sie den Servicezustand transparent an Ihre Kunden — Live-Gesamtstatus, eine Aufschlüsselung pro Service und eine kurze Historie der letzten Vorfälle und Wartungen. Jede Seite ist vollständig brandbar und kann auf Ihrer eigenen Domain laufen (z.B. status.example.com).
Summary: <Cards> <Card title="Design & Branding" href="/status-pages/design"> 8 Layouts, Farbschemata, Akzentfarbe, eigener Titel und Schalter für die Anzeige. </Card> <Card title="Eigene Domains" href="/status-pages/custom-domains"> Betreiben Sie eine Seite auf `status.example.com` mit DNS-Verifizierung und automatischem HTTPS. </Card> <Card title="Statusseiten-API" href="/api/status-pages"> Erstellen, aktualisieren, gestalten und Domains programmatisch verwalten. </Card> </Cards> ## Was eine Statusseite zeigt - **Gesamtstatus** — ein einzelnes Banner: Operativ, Beeinträchtigt oder Wartung. - **Services** — die überwachten Websites und Service-Monitore des Kunden, jeweils mit eigenem Status. - **Uptime-Statistiken** — optionale Verfügbarkeitsprozente pro Service. - **Letzte Historie** — optionale Liste der jüngsten Vorfälle und Wartungen. ### Wie der öffentliche Status abgeleitet wird Uptimeify berechnet den öffentlichen Status jedes Service aus zwei Live-Signalen — Rohdaten der Checks werden nie offengelegt: | Bedingung | Öffentlicher Status | |-----------|---------------------| | Ein oder mehrere **offene Vorfälle** | **Beeinträchtigt** | | **Aktives Wartungsfenster** und keine offenen Vorfälle | **Wartung** | | Keines davon | **Operativ** | Das Gesamt-Banner spiegelt den schlechtesten Status über alle Services wider. Siehe [Vorfälle](/incidents) und [Wartung](/maintenance) dazu, wie diese Signale entstehen. ## Statusseite erstellen In der App: **Dashboard → Statusseiten → Erstellen**. Eine Seite gehört immer zu genau einem **Kunden** — sie zeigt dessen Services. | Einstellung | Beschreibung | |-------------|--------------| | **Kunde** | Pflichtfeld. Der Kunde, dessen Services die Seite anzeigt. | | **Öffentlicher Name** | Der für Besucher sichtbare Seitentitel. | | **Slug** | Für die freundliche URL. Wird aus dem Namen generiert; Kleinbuchstaben, Ziffern und Bindestriche. | | **Beschreibung** | Optionaler Einleitungstext unter dem Titel. | | **Sichtbarkeit** | `public` (für alle sichtbar) oder `customer_members_only` (Login + Zugriff auf den Kunden nötig). | | **Veröffentlicht** | Ausschalten, um die Seite ohne Löschen zu verbergen. | All das geht auch per [API](/de/api/status-pages/create-status-page). ## URLs Jede Statusseite ist erreichbar unter: - `/status/<slug>` — freundliche URL basierend auf dem konfigurierten Slug. - `/status/<id>` — stabile URL basierend auf der Seiten-ID (immer verfügbar, auch wenn sich der Slug ändert). Mit einer aktiven [eigenen Domain](/status-pages/custom-domains) wird die Seite zusätzlich am Apex dieses Hostnamens ausgeliefert, z.B. `https://status.example.com/`. ## Sichtbarkeit & Veröffentlichung - **`public`** — die Seite ist für jeden mit dem Link erreichbar. Ideal für kundenseitigen Status. - **`customer_members_only`** — Besucher müssen eingeloggt sein und Zugriff auf den Kunden haben. Ideal für interne oder NDA-gebundene Services. - **Veröffentlicht** ist unabhängig von der Sichtbarkeit: Eine nicht veröffentlichte Seite liefert *nicht gefunden* — unabhängig von der Sichtbarkeit. Praktisch, solange Sie die Seite noch einrichten. ## Letzte Historie Der Abschnitt **Letzte Historie** wird über zwei unabhängige Schalter gesteuert: - **Letzte Vorfälle anzeigen** - **Letzte Wartungen anzeigen** Diese betreffen nur die *Historien-Liste*. Live-Indikatoren (etwa ein Service, der gerade in Wartung ist) werden unabhängig davon immer angezeigt. Die [Design-Einstellungen](/status-pages/design) steuern zusätzlich das Zeitfenster der Historie (`historyDays`). ## Fehlerbehebung ### „Statusseite nicht gefunden" - Prüfen Sie, ob die Seite **veröffentlicht** ist. - Bei Sichtbarkeit `customer_members_only` müssen Sie eingeloggt sein und Zugriff auf diesen Kunden haben. - Prüfen Sie den Slug — er wird beim Speichern auf Kleinbuchstaben-mit-Bindestrichen normalisiert. ### Ein Service zeigt den falschen Status - **Bleibt auf Beeinträchtigt?** Es gibt noch einen offenen Vorfall für diesen Service — lösen Sie ihn auf o…

### Eigene Domains
URL: https://docs.uptimeify.io/de/status-pages/custom-domains
Description: Verbinden Sie einen Hostnamen wie status.example.com mit einer Statusseite, damit sie vollständig unter Ihrer Marke läuft. Ein Hostname kann an genau eine Statusseite gebunden werden, und das Zertifikat wird automatisch ausgestellt, sobald die Domain verifiziert und aktiv ist.
Summary: ## So funktioniert es Eine eigene Domain durchläuft drei Zustände: 1. **Ausstehend** — hinzugefügt, wartet auf DNS-Verifizierung. 2. **Verifiziert** — der TXT-Eintrag wurde gefunden; bereit zur Aktivierung. 3. **Aktiv** — die Seite wird über HTTPS auf dem Hostnamen ausgeliefert. ``` Hostname hinzufügen → TXT-Eintrag setzen → Verifizieren → Aktivieren → CNAME setzen (ausstehend) (Ihr DNS) (verifiziert) (aktiv) (Traffic) ``` ## Schritt 1 — Hostname hinzufügen In der App: **Dashboard → Statusseiten → (Seite) → Eigene Domain → Hinzufügen**, geben Sie `status.example.com` ein. Per API: [Eigene Domain hinzufügen](/de/api/status-pages/add-status-page-domain). Uptimeify liefert einen TXT-Verifizierungseintrag: - **TXT-Name**: `_uptimeify-verify.status.example.com` - **TXT-Wert**: das in App/API-Antwort angezeigte Token ## Schritt 2 — TXT-Eintrag setzen Legen Sie den TXT-Eintrag bei Ihrem DNS-Anbieter exakt wie angezeigt an. Lassen Sie ihn bestehen — er wird auch laufend erneut geprüft. <Callout type="info"> DNS-Änderungen brauchen von wenigen Minuten bis zu mehreren Stunden, um sich zu verbreiten. Schlägt die Verifizierung sofort fehl, warten Sie und versuchen Sie es erneut. </Callout> ## Schritt 3 — Verifizieren Klicken Sie auf **Verifizieren** (oder rufen Sie [Statusseiten-Domain verifizieren](/de/api/status-pages/verify-status-page-domain) auf). Uptimeify schlägt den TXT-Eintrag nach und prüft, ob das Token übereinstimmt. Bei Erfolg wird die Domain **Verifiziert**. ## Schritt 4 — Aktivieren Klicken Sie auf **Aktivieren** (oder rufen Sie [Statusseiten-Domain aktivieren](/de/api/status-pages/activate-status-page-domain) auf). Die Domain wird **Aktiv** und ein TLS-Zertifikat wird automatisch bereitgestellt (On-Demand-HTTPS) — kein Zertifikats-Upload nötig. ## Schritt 5 — Traffic zu Uptimeify leiten Zeigen Sie den Hostnamen schließlich auf Uptimeify, damit Besucher die Seite tatsächlich erreichen — legen Sie den in der App angezeigten CNAME für `status.example.com` an. Sobald DNS auflöst, liefert `https://status.example.com/` Ihre Statusseite aus. <Callout type="warn"> Lassen Sie beide Einträge bestehen: den **TXT**-Eintrag (für die laufende Verifizierung) und den **CNAME** (leitet Besucher-Traffic). Das Entfernen des TXT-Eintrags kann dazu führen, dass die Domain die erneute Verifizierung nicht besteht. </Callout> ## Domain entfernen Entfernen Sie die Bindung in der App oder über [Eigene Domain entfernen](/de/api/status-pages/remove-status-page-domain). Die Statusseite bleibt über ihre URLs `/status/<slug>` und `/status/<id>` erreichbar. ## Fehlerbehebung ### „TXT-Verifizierung fehlgeschlagen (Token nicht gefunden)" - Prüfen Sie, dass der TXT-**Name** exakt `_uptimeify-verify.<Ihr-Hostname>` lautet. - Prüfen Sie, dass der TXT-**Wert** dem Token von Uptimeify entspricht (keine zusätzlichen Anführungszeichen oder Leerzeichen). - Geben Sie DNS mehr Zeit zur Verbreitung und verifizieren Sie erneut. - Prüfen Sie, dass der Eintrag nicht in der falschen Zone liegt (z.B. Apex statt Subdomain). ### Die Seite lädt nicht auf meiner Domain - Stellen Sie sicher, dass die Domain **Aktiv** ist, nicht nur Verifiziert. - Prüfen Sie, dass der **CNAME** auf das in der App angezeigte Ziel zeigt. - Die erste Anfrage nach der Aktivierung kann etwas langsamer sein, während das Zertifikat ausgestellt wird.

### Design & Branding
URL: https://docs.uptimeify.io/de/status-pages/design
Description: Jede Statusseite hat eine visuelle Design-Konfiguration. Bearbeiten Sie sie in der App unter Dashboard → Statusseiten → (Seite) → Design oder über die Design-API. Änderungen werden zusammengeführt — Sie senden nur die Felder, die Sie ändern möchten, der Rest behält seine aktuellen Werte.
Summary: ## Layouts Wählen Sie eines von acht Layout-Presets. Alle zeigen dieselben Daten (Gesamtstatus, Services, optionale Statistiken und Historie), unterscheiden sich aber in Struktur und Dichte — sehen Sie sich jedes im Design-Editor live an. | Layout | Ideal für | |--------|-----------| | `classic` | Der Standard. Prominentes Hero-Banner mit dem Gesamtstatus, gefolgt von der Service-Liste. | | `cards` | Jeder Service als Karte in einem responsiven Raster. | | `minimal` | Reduzierte, textorientierte Darstellung mit minimalem Rahmen. | | `sleek` | Modernes Hero-Banner mit Akzentfarben-Verlauf. | | `board` | Dashboard-artiges Board, um viele Services auf einen Blick zu sehen. | | `split` | Header über die volle Breite mit zweispaltigem Body (Status neben Historie). | | `timeline` | Betont eine chronologische Timeline von Vorfällen und Wartungen. | | `compact` | Dichtes Layout, das viele Services auf wenig vertikalem Raum unterbringt. | ## Erscheinungsbild | Option | Werte | Standard | Beschreibung | |--------|-------|----------|--------------| | `colorScheme` | `light`, `dark`, `auto` | `auto` | `auto` folgt der Systemeinstellung des Besuchers. | | `accentColor` | Hex-Farbe `#rrggbb` | `#6366f1` | Für Hervorhebungen, Links und Verläufe. | | `headerStyle` | `simple`, `centered`, `hero` | `simple` | Wie prominent der Seiten-Header ist. | | `fontFamily` | `system`, `mono` | `system` | `mono` gibt einen technischen, dicktengleichen Look. | | `cardRadius` | `none`, `md`, `xl` | `md` | Eckenrundung von Karten und Panels. | | `pageWidth` | `sm`, `md`, `lg`, `xl` | `lg` | Maximale Inhaltsbreite. | ## Inhalt & Abschnitte | Option | Typ | Standard | Beschreibung | |--------|-----|----------|--------------| | `customTitle` | String (≤120) | — | Überschreibt den Seitentitel im Header. | | `customSubtitle` | String (≤200) | — | Ein Untertitel unter dem Titel. | | `showUptimeStats` | Boolean | `true` | Verfügbarkeitsprozente pro Service anzeigen. | | `showServiceUrls` | Boolean | `false` | Die URL jedes Service neben dem Namen anzeigen. | | `showLastChecked` | Boolean | `false` | Den „zuletzt geprüft"-Zeitstempel pro Service anzeigen. | | `showHistory` | Boolean | `true` | Den Abschnitt „Letzte Historie" anzeigen. | | `historyDays` | Zahl | — | Wie viele Tage Historie einbezogen werden (begrenzt durch das Plattform-Min/Max). | | `showPoweredBy` | Boolean | `true` | Den „powered by Uptimeify"-Footer anzeigen. Für volles White-Labeling ausschalten. | <Callout> `showHistory` steuert, ob der Historien-*Abschnitt* gerendert wird. Die separaten Schalter **Letzte Vorfälle anzeigen** und **Letzte Wartungen anzeigen** (in den Haupteinstellungen der Seite) steuern, *was* in diesen Abschnitt kommt. Siehe [Letzte Historie](/status-pages#letzte-historie). </Callout> ## Beispiel (API) ```bash curl -X PATCH "$BASE_URL/api/status-pages/<id>/design" \ -H "Authorization: Bearer $TOKEN" \ -H "Content-Type: application/json" \ -d '{ "layout": "sleek", "colorScheme": "dark", "accentColor": "#10b981", "showServiceUrls": true, "showPoweredBy": false }' ``` Nur die gesendeten Felder werden geändert; alles andere behält seinen aktuellen Wert. Siehe [Statusseiten-Design aktualisieren](/de/api/status-pages/update-status-page-design) für die vollständige Referenz. ## White-Labeling Für eine vollständig gebrandete Seite ohne Uptimeify-Verweise: 1. Setzen Sie `showPoweredBy` auf `false`. 2. Konfigurieren Sie eine [eigene Domain](/status-pages/custom-domains), damit die Seite auf Ihrem Hostnamen läuft. 3. Setzen Sie eine `accentColor` (und optional `customTitle`/`customSubtitle`) passend zu Ihrer Marke.