HTTP-API, OAuth und MCP

API-Referenz

Laden Sie den englischen OpenAPI-Vertrag oder den deutschen Vertrag herunter. API-Pfade und technische Kennungen sind in beiden Sprachen identisch.

• GET OAuth-Autorisierungsserver ermitteln

  OAuth-Autorisierungsserver ermitteln.

• GET Geschützte MCP-Ressource ermitteln

  Geschützte MCP-Ressource ermitteln.

• POST Eigenes Konto deaktivieren und Löschung einreihen

  Löschen Sie Ihr eigenes Konto nach Bestätigung mit einem frischen Aktionscode. Der Zugriff endet sofort; Messdaten und Dateien werden anschließend im Hintergrund entfernt.

• PATCH Sprachpräferenzen des Kontos speichern

  Eine oder mehrere Kontoeinstellungen ändern. Ausgelassene Einstellungen bleiben erhalten. Eine Browsersitzung und ein CSRF-Token sind erforderlich.

• GET Angenommenen Heartbeat und aktivierten Messwert bestätigen

  Bestätigen Sie das ausgewählte Agent-Profil anhand gespeicherter Daten: ein Lebenszeichen sowie ein Zahlen- oder Zustandswert einer aktivierten Profilreihe, empfangen seit dem angegebenen Zeitpunkt. Installer- und Prozessstatus bestätigen keine Betriebsbereitschaft.

• GET Einen kurzen Bestätigungscode als angemeldeter Nutzer prüfen

  Einen kurzen Bestätigungscode als angemeldeter Nutzer prüfen

• POST Gerät und separate CLI-/MCP-Verwaltungskennung freigeben

  CSRF erforderlich. Eigenen Arbeitsbereich auswählen oder anlegen; unkonfigurierten Server auswählen oder anlegen. Standard sind CPU, RAM und Systemlaufwerk alle 30 Sekunden. Kontokontingente werden in derselben Transaktion geprüft. Wiederholungen desselben Kontos erzeugen keine weiteren Schlüssel; ein anderes Konto kann abgeschlossene Anfragen nicht freigeben.

• POST Ausstehende Geräte-Verknüpfung ablehnen

  Ausstehende Geräte-Verknüpfung ablehnen

• POST Eine Geräte-Verknüpfung mit zehn Minuten Laufzeit starten

  Geheimnisse lokal erzeugen und nur Hashes übertragen. Eine identische Wiederholung mit demselben Client-Token liefert dieselbe Challenge. Es wird kein Konto erstellt.

• DELETE Geräte-Verknüpfung abbrechen und dadurch ausgestellte Zugangsdaten widerrufen

  Geräte-Verknüpfung abbrechen und dadurch ausgestellte Zugangsdaten widerrufen

• GET Den Status der Geräte-Verknüpfung abfragen

  Den Status der Geräte-Verknüpfung abfragen

• GET Dem Geräteschlüssel zugeordnetes Profil lesen

  Der gerätegebundene Schlüssel liest ausschließlich das Profil seines aktiven Servermonitors und zugewiesene Reihen. Freigaben und Kontogrenzen gelten weiterhin.

• POST Erkannte Serverkomponenten und Erfassungsstatus melden

  Erkennung sowie unsupported-/permission_denied-Berichte sind keine Messwerte und aktivieren keine Auswahl. Angenommene Berichte ändern ausschließlich den Servermonitor des Schlüssels.

• GET Eigene Vorfallhistorie lesen

  Lesen Sie alle gespeicherten Vorfälle ohne Altersgrenze. Verwenden Sie next_cursor, um ältere Seiten zu laden. Eine Seite enthält standardmäßig 50 und höchstens 100 Vorfälle. Behalten Sie Arbeitsbereich und Zustandsfilter beim Blättern bei. Vorfallzusammenfassungen bleiben bis zur Kontolöschung erhalten; Zustelldetails verfallen nach 90 Tagen. Bereits entfernte Vorfälle können nicht wiederhergestellt werden.

• POST Eigenen Vorfall bestätigen

  Eigenen Vorfall bestätigen.

• GET Zustellversuche nach Kanal für einen Vorfall lesen

  Zustellversuche nach Kanal für einen Vorfall lesen.

• GET Auswertungsbelege eines Vorfalls lesen

  Liefert die tatsächlich aufgezeichneten, begrenzten Auswertungssnapshots für Auslösung und Entwarnung sowie Gründe unterdrückter Zustellungen. Bestehende Vorfälle ohne Snapshot liefern null; die verfügbare Messwerthistorie belegt nicht die damalige Auswertung. Aktueller Entwarnungsfortschritt ist nur für denselben noch aktiven Vorfall bei unveränderter Regelversion verfügbar. Erfordert telemetry:read und Zugriff auf den Arbeitsbereich des Vorfalls.

• DELETE Eigenes Wartungsfenster entfernen

  Eigenes Wartungsfenster entfernen.

• GET Aktive Regeln und gespeicherten Alarmzustand lesen

  Zugängliche aktive Regeln seitenweise mit 50 (höchstens 100) Einträgen lesen. Regel- und Monitornamen durchsuchen und Typ, Schwere oder Zustand vor der Seiteneinteilung filtern. next_cursor mit denselben Filtern, derselben Sortierung und Seitengröße verwenden; ein leerer Cursor kennzeichnet das Ende. Cursor verfallen nach 15 Minuten. Pausierte und stummgeschaltete Regeln bleiben verfügbar.

• POST Regel für Messwert, Zustand, Text, Datenlücke oder Lauf erstellen

  Regel für Messwert, Zustand, Text, Datenlücke oder Lauf erstellen.

• DELETE Regel archivieren und offene Vorfälle schließen

  Regel archivieren und offene Vorfälle schließen.

• GET Eine Alarmregel lesen

  Öffnen Sie eine zugängliche Alarmregel über ihre Kennung, unabhängig von Listenfiltern und Seiten.

• PUT Eine individuelle Regel mit expected_version bearbeiten. Monitor, Messreihe und Regeltyp bleiben fest; verwaltete Regeln verwenden ihren Konfigurationseditor. Eine neue Evidenzrevision erhält die Vorfallhistorie.

  Eine individuelle Regel mit expected_version bearbeiten. Monitor, Messreihe und Regeltyp bleiben fest; verwaltete Regeln verwenden ihren Konfigurationseditor. Eine neue Evidenzrevision erhält die Vorfallhistorie.

• GET Wartungsfenster der eigenen Regel lesen

  Wartungsfenster der eigenen Regel lesen.

• POST Wartungsfenster für eigene Regel erstellen

  Wartung verhindert neue Auslöse- und Entwarnungsauswertungen im gewählten Fenster. Vorhandene Fenster und Vorfälle bleiben sichtbar.

• POST Auswertung pausieren oder Zustellung bis zu einem Zeitpunkt stummschalten

  Pausieren stoppt die Regelauswertung; Stummschalten unterdrückt Kanalzustellung, während Vorfälle sichtbar bleiben. Ein endlicher UTC-until-Zeitpunkt ist erforderlich.

• PUT Zielauswahl einer Alarmregel ändern

  CSRF-geschützt. Neue Auswahl gilt ab dem nächsten Vorfall; der bestehende Zielsatz bleibt gespeichert.

• POST Auswertung pausieren oder Zustellung bis zu einem Zeitpunkt stummschalten

  Pausieren stoppt die Regelauswertung; Stummschalten unterdrückt Kanalzustellung, während Vorfälle sichtbar bleiben. Ein endlicher UTC-until-Zeitpunkt ist erforderlich.

• POST Auswertung fortsetzen oder Zustellung wieder aktivieren

  Entfernt das jeweilige Pause-/Stummschaltungsfeld einer eigenen aktiven Regel. Schwellenwerte und vorhandene Historie ändern sich dadurch nicht.

• POST Auswertung fortsetzen oder Zustellung wieder aktivieren

  Entfernt das jeweilige Pause-/Stummschaltungsfeld einer eigenen aktiven Regel. Schwellenwerte und vorhandene Historie ändern sich dadurch nicht.

• GET Aktuelle Testmailversuche lesen

  Aktuelle Testmailversuche lesen.

• POST Testmail an die bestätigte eigene Adresse einreihen

  Testmail an die bestätigte eigene Adresse einreihen.

• DELETE Analysejob abbrechen

  Arbeitsbereichs-SLOs verwenden die Gesamtverfügbarkeitsreihe von HTTP-, TCP-, UDP-, DNS-, TLS-, Ping-, Dienst-, Domain- und Browsermonitoren. Unbekannte und unbeobachtete Zeit bleiben ausdrücklich sichtbar; erst die untere Verfügbarkeitsgrenze belegt die Zielerfüllung. Je Arbeitsbereich gelten zehn SLOs und drei Berichtpläne. Kalenderberichte bleiben 90 Tage unveränderlich. E-Mail benötigt die ausdrückliche Freigabe des Owners sowie ein bestätigtes Ziel und teilt das vorhandene Zustellkontingent. Abbrechbare Analysejobs teilen vier globale Plätze und einen je Owner; Arbeitsbereichsgrenzen bleiben verbindlich. Wählen Sie tägliche, wöchentliche oder monatliche Berichte und eine Versandzeit (HH:MM) in einer IANA-Zeitzone. Der Bericht umfasst den vorigen lokalen Kalendertag, die vorige Woche von Montag bis Sonntag oder den vorigen Monat. Die Erstellung startet zur gewählten Zeit; die Zustellung kann später erfolgen. Bei der Zeitumstellung wird eine fehlende Uhrzeit auf die nächste gültige Minute verschoben und eine doppelte Uhrzeit nur einmal verwendet. Die manuelle Erstellung verwendet unabhängig von der Versandzeit den letzten abgeschlossenen Zeitraum.

• GET Analysejob lesen

  Arbeitsbereichs-SLOs verwenden die Gesamtverfügbarkeitsreihe von HTTP-, TCP-, UDP-, DNS-, TLS-, Ping-, Dienst-, Domain- und Browsermonitoren. Unbekannte und unbeobachtete Zeit bleiben ausdrücklich sichtbar; erst die untere Verfügbarkeitsgrenze belegt die Zielerfüllung. Je Arbeitsbereich gelten zehn SLOs und drei Berichtpläne. Kalenderberichte bleiben 90 Tage unveränderlich. E-Mail benötigt die ausdrückliche Freigabe des Owners sowie ein bestätigtes Ziel und teilt das vorhandene Zustellkontingent. Abbrechbare Analysejobs teilen vier globale Plätze und einen je Owner; Arbeitsbereichsgrenzen bleiben verbindlich. Wählen Sie tägliche, wöchentliche oder monatliche Berichte und eine Versandzeit (HH:MM) in einer IANA-Zeitzone. Der Bericht umfasst den vorigen lokalen Kalendertag, die vorige Woche von Montag bis Sonntag oder den vorigen Monat. Die Erstellung startet zur gewählten Zeit; die Zustellung kann später erfolgen. Bei der Zeitumstellung wird eine fehlende Uhrzeit auf die nächste gültige Minute verschoben und eine doppelte Uhrzeit nur einmal verwendet. Die manuelle Erstellung verwendet unabhängig von der Versandzeit den letzten abgeschlossenen Zeitraum.

• GET Abgeschlossenen Bericht als CSV exportieren

  Laden Sie den CSV-Export eines abgeschlossenen Periodenberichts herunter. SLO-Auswertungsaufträge liefern JSON und beim CSV-Abruf csv_not_supported (422); unfertige Berichtaufträge liefern job_not_ready (409).

• POST Freigegebene Archivabfrage einreihen

  Exportieren Sie numerische Historien mit Original-, Minuten-, Viertelstunden- oder Stundenauflösung. Mit multipart=true gelten bis zu 60.000 Messwerte und 25 MiB in höchstens 64 Dateien; jede Datei enthält höchstens 2.000 Messwerte und 512 KiB. preview=true schätzt die Größe ohne Auftrag. Ohne multipart gelten die bisherigen Einzeldateigrenzen. Abgeschlossene Aufträge enthalten Prüfsummen und Links für jeden Teil. UTC-Zeiten, Datenabdeckung, Lücken und verfügbare Zählerzuwächse/-resets bleiben erhalten. Scheitert der gesamte Export, wird kein Teil veröffentlicht. Brechen Sie nicht mehr benötigte laufende Aufträge ab; Downloads verfallen nach einem Tag. Zustands- und Ereignishistorien bleiben als JSON verfügbar.

• DELETE Eigenen ausstehenden oder laufenden Archivauftrag abbrechen

  Eigenen ausstehenden oder laufenden Archivauftrag abbrechen.

• GET Archivauftrag und sein begrenztes Ergebnis lesen

  Lesen Sie Status und Fortschritt Ihres berechtigten Historienauftrags. Abgeschlossene mehrteilige CSV-Exporte enthalten alle Downloadlinks, Zeilenzahlen, Größen, SHA-256-Prüfsummen und Datenabdeckung im Ergebnis. Vor Abschluss des gesamten Zeitraums ist kein Teil verfügbar.

• PATCH API: Historienauftrag fortsetzen

  Bestätigen Sie, dass Ihr eigener eingereihter, laufender oder abgeschlossener Historien- oder CSV-Auftrag beim Schließen der Seite erhalten bleibt. Abfragezeitpunkt und Kontingente bleiben gleich. Sie können weiterhin ausdrücklich abbrechen.

• GET Fertigen CSV-Export herunterladen

  Nur ein abgeschlossener eigener CSV-Auftrag ist abrufbar. Führende Formelzeichen werden entschärft. Abgelaufene oder fehlende Ergebnisse sind nicht durch Erraten eines Dateinamens wiederherstellbar.

• POST Code für eine einzelne sensible Aktion anfordern

  Fordern Sie einen sechsstelligen Bestätigungscode für eine sensible Konto- oder Arbeitsbereichsänderung an. Er gilt fünf Minuten und erlaubt fünf Fehlversuche. Nutzen Sie zur Bestätigung denselben angemeldeten Browser, dieselbe Aktion, dasselbe Ziel und dieselben Parameter. Ein nach 60 Sekunden angeforderter Ersatz macht den bisherigen Code dieser Aktion ungültig. Für Ihr Konto nutzen Sie link_identity, unlink_identity, add_passkey, remove_passkey oder delete_self; Mitgliedschaftsaktionen brauchen Besitzerrechte. Anmeldecodes bestätigen keine Änderungen.

• DELETE Eigene ausstehende Aktionsbestätigung abbrechen

  Nur eine ausstehende Bestätigung des aktuellen Kontos und der aktuellen Sitzung kann abgebrochen werden.

• POST Neue E-Mail-Adresse bestätigen und Sitzungen widerrufen

  Neue E-Mail-Adresse bestätigen und Sitzungen widerrufen.

• DELETE Browsereinstieg abbrechen

  Entwertet offene E-Mail-Challenges und den browsergebundenen Einstieg und entfernt dessen Voranmeldecookie. Eine bestehende Anwendungssitzung wird nicht widerrufen. Erfordert die erlaubte Browserherkunft.

• GET Aktuellen Browsereinstieg lesen

  Liest den an __Host-mb_auth gebundenen Ablauf ohne Anwendungssitzung anzulegen. Fehlende, abgelaufene, abgeschlossene oder abgebrochene Abläufe liefern status idle. Aktive Abläufe beschreiben Nachweis, Zustimmung oder ausdrückliche Identitätsverknüpfung.

• POST Aktuelle Rechtstexte bestätigen und Einstieg abschließen

  Schließen Sie die Registrierung nach Identitätsbestätigung durch Annahme der aktuellen Nutzungsbedingungen und Kenntnisnahme des Datenschutzes ab. Eine erfolgreiche Antwort erstellt die Browsersitzung. Neue Konten benötigen eine offene Registrierung.

• POST E-Mail-Nachweis im anfordernden Browser bestätigen

  Akzeptiert genau eine Nachweisform: Link-Token oder challenge_id mit sechsstelligem Code. Nachweis und Ablauf sind browsergebunden und einmalig; höchstens fünf Fehlversuche sind erlaubt. Bestehende bestätigte E-Mail-Konten erhalten eine siebentägige Sitzung. Neue Konten wechseln zu consent_required; Anbieteridentitäten für ein bestehendes Konto zu link_confirmation_required ohne automatische Verknüpfung.

• POST E-Mail-Nachweis für Browsereinstieg anfordern

  Fordert einen zehn Minuten gültigen Magic Link und sechsstelligen Code für den anfordernden Browser an. Ein aktives bestätigtes Konto kann unabhängig vom Registrierungsgate anmelden. Ein neues menschliches Konto entsteht nur bei freigegebener Registrierung und eingehaltenen Grenzen; nach dem Nachweis bleibt aktuelle rechtliche Zustimmung erforderlich. Die 202-Antwort verrät keinen Mailversand. Erneutes Anfordern innerhalb von 60 Sekunden liefert die bestehende Challenge; spätere Anfragen ersetzen nur diesen Browserablauf.

• POST Identitätsverknüpfung ausdrücklich bestätigen

  Bestätigen Sie die angezeigte Anmeldeanbieter-Verbindung im ursprünglichen Browser. Senden Sie Bestätigungstoken oder challenge_id und Code; bei mail_verified true bestätigt ein leeres Objekt die geprüfte Verbindung.

• GET Verknüpfte Identitäten und ausstehende Verknüpfungen lesen

  Verknüpfte Identitäten und ausstehende Verknüpfungen lesen.

• DELETE Anbieteridentität mit Aktionscode trennen

  Der Code bindet Anbieter und Identitäts-ID. Trennen widerruft Browsersitzungen; melden Sie sich erneut per E-Mail an. Maschinenidentität, Ursprung, Kontingente und Telemetrie bleiben erhalten.

• POST Bestätigte Anbieteridentität mit Aktionscode verknüpfen

  Ein Anbietercallback muss für einen Versuch dieser Sitzung abgeschlossen sein. Der Code bindet Anbieter und Versuchs-ID. Eine Anbieteridentität gehört höchstens zu einem Konto.

• POST Einladung ausdrücklich und ohne Passwort annehmen

  Einladung ausdrücklich und ohne Passwort annehmen.

• POST Stillgelegter Passwortendpunkt: E-Mail-Anmeldung verwenden

  Antwortet immer mit HTTP 410. Fordern Sie stattdessen einen Magic Link oder Anmeldecode an. Diese Operation meldet niemanden an und ändert kein Passwort.

• POST Loginlink oder Code bestätigen und Sitzung erstellen

  Bestätigen Sie die E-Mail-Anmeldeanfrage ausdrücklich, um eine siebentägige Browsersitzung zu erstellen. Der Linkaufruf allein meldet nicht an. Nutzen Sie bei einem anderen Browser den Code im Browser der ursprünglichen Anfrage.

• POST Browsergebundenen Magic Link und Anmeldecode anfordern

  Magic Link und sechsstelliger Code gehören zu derselben zehn Minuten gültigen Anfrage. Das Secure-/HttpOnly-Cookie zur Browserbindung ist erforderlich. Antworten verraten keine unbekannten oder gesperrten Konten. return_to ist auf erlaubte lokale App- oder OAuth-Zustimmungspfade begrenzt.

• POST Aktuelle Browsersitzung beenden

  Aktuelle Browsersitzung beenden.

• POST Einmalige Ed25519-Maschinenchallenge anfordern

  Die Registrierung beziehungsweise Wiederherstellung muss für den angeforderten Zweck freigegeben sein. Speichern Sie private Ed25519-Recoveryidentität und vorgesehenes Verwaltungscredential lokal vor der Anfrage. Die Challenge bindet Zweck und öffentlichen Schlüssel und gilt fünf Minuten.

• POST E-Mail-Bestätigung für Maschinenkonto anfordern

  Benötigt account:write beim Maschinencredential. Die bisherige bestätigte Adresse und Kontostufe bleiben bis zur Bestätigung gültig. Antworten sind bei bereits verwendeten Adressen einheitlich.

• POST Maschinen-Verwaltungszugang per Recovery ersetzen

  Signieren Sie eine frische recover-Challenge mit der vorhandenen Recoveryidentität. Speichern Sie das Ersatzcredential vor der Anfrage. Wiederholung mit einer frischen Challenge ergibt dasselbe Konto und liefert kein Geheimnis zurück.

• POST Maschinenkonto registrieren oder abrufen

  Die Ed25519-Signatur der Version 2 bindet Challenge, beide Rechtstextversionen und Bestätigungen. Gespeichert wird nur der SHA-256-Credentialhash. Wiederholung benötigt eine frische Challenge und dasselbe lokal gespeicherte Credential.

• POST Kurzlebiges ressourcengebundenes MCP-Token ausstellen

  Benötigt account:read und freigegebenen entfernten MCP-Zugang. Angeforderte Scopes müssen eine Teilmenge des Verwaltungscredentials sein. Nur die eigene kanonische /mcp-Resource wird akzeptiert. Widerruf des Ursprungscredentials widerruft abgeleiteten Zugriff sofort.

• GET Angemeldetes Konto lesen

  Angemeldetes Konto lesen.

• GET Anbieterrückruf im ursprünglichen Browser bestätigen

  Prüft Browserbindung, State, PKCE und Anbieteridentität. Tokens gelangen nicht in Rücksprung-URLs. Vorhandene Mailkonten benötigen ausdrückliche Verknüpfung statt automatischer Zuordnung.

• POST Anmeldung, Registrierung oder Identitätsverknüpfung starten

  login, register und link haben getrennte Zwecke. Registrierung verlangt Freigabe und aktuelle Rechtstextbestätigung. Verknüpfen benötigt Browsersitzung und später frischen Aktionscode. Browsercookie, State und PKCE binden den Ablauf zehn Minuten.

• GET Eigene Passkeys auflisten

  Listet ausschließlich Namen und Zeitpunkte der Passkeys des verifizierten Kontos. Öffentliche Schlüssel und Credential-IDs werden nicht ausgegeben. Der Schalter steuert Einrichtung und Anmeldung; Entfernen bleibt möglich.

• POST Passkey-Anmeldung abschließen

  Prüft Signatur, Benutzerverifikation, Origin, Kontostatus und browsergebundene einmalige Challenge vor dem Erstellen einer normalen Sitzung. Fehler geben keine Auskunft über Konten. Grenze: vierzig Versuche je Netzadresse in fünfzehn Minuten.

• POST Passkey-Anmeldung starten

  Erzeugt eine auffindbare Challenge ohne Mailadresse oder Kontosuche. Erfordert die konfigurierte Origin und ein browsergebundenes Cookie. Grenze: zwanzig Starts je Netzadresse in fünfzehn Minuten.

• POST Passkey-Einrichtung abschließen

  Schließen Sie die Passkey-Einrichtung mit der WebAuthn-Geräteantwort im selben angemeldeten Browser ab. Pro Konto können bis zu zehn Passkeys gespeichert werden.

• POST Passkey-Einrichtung freigeben

  Erfordert ein vollständig aktiviertes Konto, eine Browsersitzung und eine frische add_passkey-Mailbestätigung für den bereinigten Namen. Verbraucht die Bestätigung und liefert eine einmalige Einrichtungsfreigabe für fünf Minuten. Legt kein Konto an.

• DELETE Passkey entfernen

  Erfordert eine frische remove_passkey-Bestätigung für diese Schlüssel-ID. Entfernt den Schlüssel und beendet alle Browsersitzungen; die Mailanmeldung bleibt verfügbar.

• PATCH Passkey umbenennen

  Benennt einen eigenen Passkey um, ohne Authentifizierungsdaten zu ändern. Erfordert die aktive Browsersitzung und ein CSRF-Token.

• POST Stillgelegter Passwortendpunkt: E-Mail-Anmeldung verwenden

  Antwortet immer mit HTTP 410. Fordern Sie stattdessen einen Magic Link oder Anmeldecode an. Diese Operation meldet niemanden an und ändert kein Passwort.

• GET Verfügbare Google- und GitHub-Anbieter lesen

  Nur konfigurierte Anbieter werden aufgeführt. Anmeldung erzeugt niemals stillschweigend ein Konto und verknüpft keine vorhandene passende Mailadresse automatisch.

• POST Passwortfrei registrieren und Bestätigung anfordern

  Registrierung verlangt aktuelle Freigabe und Rechtstextbestätigungen. Vorhandene Adressen erzeugen keine doppelten Konten. Bestätigung und erste Anmeldung verwenden dieselbe browsergebundene Link-/Codeanfrage.

• POST Stillgelegter Passwortendpunkt: E-Mail-Anmeldung verwenden

  Antwortet immer mit HTTP 410. Fordern Sie stattdessen einen Magic Link oder Anmeldecode an. Diese Operation meldet niemanden an und ändert kein Passwort.

• POST Stillgelegter Passwortendpunkt: E-Mail-Anmeldung verwenden

  Antwortet immer mit HTTP 410. Fordern Sie stattdessen einen Magic Link oder Anmeldecode an. Diese Operation meldet niemanden an und ändert kein Passwort.

• GET Eigene aktive Sitzungen ohne Geheimnisse lesen

  Aktive Browsersitzungen mit groben Gerätehinweisen und erfasster Aktivität auflisten. Sitzungen werden seitenweise geliefert; Maschinencredentials können diesen Endpunkt nicht aufrufen.

• DELETE Alle anderen aktiven Browsersitzungen beenden

  Alle anderen aktiven Browsersitzungen beenden, einschließlich Sitzungen außerhalb der geladenen Seiten. Aktuelle Sitzung und Konto werden innerhalb der Transaktion erneut geprüft. Die aktuelle Sitzung, Maschinencredentials, Geräteschlüssel und MCP-Tokens bleiben erhalten. Eine Wiederholung ist erfolgreich mit revoked gleich null. Es ist kein Mail-Code erforderlich.

• DELETE Eine eigene Sitzung widerrufen

  Eine eigene Sitzung widerrufen.

• POST Einmaliges Bestätigungstoken einlösen

  Einmaliges Bestätigungstoken einlösen.

• GET Aktuell freigegebene API-Funktionen lesen

  Lesen Sie aktuell verfügbare Monitoringfunktionen und die passende Vorlagenversion. Ihre eigenen Kontolimits gelten weiterhin.

• GET Gespeicherte Dashboard-Konfiguration lesen

  Passen Sie Ihr persönliches Dashboard direkt an: Verschieben Sie Karten, wählen Sie Quellen, legen Sie Titel und Breiten fest und ergänzen Sie Monitor-, Kennzahl-, Diagramm- oder Wartungskarten. Änderungen gelten erst nach dem Speichern und beachten immer den Gruppenfilter.

• PUT Dashboard-Konfiguration atomar speichern

  Passen Sie Ihr persönliches Dashboard direkt an: Verschieben Sie Karten, wählen Sie Quellen, legen Sie Titel und Breiten fest und ergänzen Sie Monitor-, Kennzahl-, Diagramm- oder Wartungskarten. Änderungen gelten erst nach dem Speichern und beachten immer den Gruppenfilter.

• GET Freigegebene Arbeitsbereichsübersicht lesen

  Passen Sie Ihr persönliches Dashboard direkt an: Verschieben Sie Karten, wählen Sie Quellen, legen Sie Titel und Breiten fest und ergänzen Sie Monitor-, Kennzahl-, Diagramm- oder Wartungskarten. Änderungen gelten erst nach dem Speichern und beachten immer den Gruppenfilter.

• GET Geräte im Arbeitsbereich suchen und seitenweise lesen

  Geräte im Arbeitsbereich suchen und seitenweise lesen.

• POST Gerät erstellen

  Gerät erstellen.

• DELETE Einen Monitor endgültig löschen

  Nur der Eigentümer des Arbeitsbereichs darf einen Monitor endgültig löschen. Zuerst eine fünf Minuten gültige, an die Konfiguration gebundene Vorschau anfordern; danach preview_id, confirm_deletion: true und einen Idempotency-Key senden. Unbestätigte alte Archivierungsaufrufe werden abgewiesen. Der Monitor wird sofort gesperrt; ein dauerhafter Auftrag entfernt seine Datenbank-, Archiv- und Cachedaten und bereinigt verknüpfte Anzeigen. Den Auftrag bis zum Abschluss abfragen; pausierte Aufträge zeigen einen technischen Fehler und werden automatisch wiederholt. Tageskontingente und Sicherheitszähler bleiben unverändert. Bereits zugestellte Nachrichten und heruntergeladene Dateien können nicht zurückgeholt werden.

• GET Eigenes aktives Gerät lesen

  Eigenes aktives Gerät lesen.

• PATCH Eigenes Gerät aktualisieren

  Eigenes Gerät aktualisieren.

• DELETE Gemeinsame Geräte-Charts zurücksetzen

  Stellen Sie automatische Diagramme und ihre ursprüngliche Anordnung mit der aktuellen Revision wieder her. Messreihen und gespeicherte Messwerte bleiben erhalten.

• GET Gemeinsame Geräte-Charts lesen

  Lesen Sie gespeicherte Zahlen-/Zustandsdiagramme, Anordnung und Revision. Nicht zugeordnete Messreihen werden weiterhin automatisch angezeigt.

• PUT Gemeinsame Geräte-Charts speichern

  Speichern Sie Zahlendiagramme mit höchstens acht Messreihen und zwei passenden Einheitenachsen oder Zustandsdiagramme mit einer Boolean-/Enum-Messreihe. Jede Messreihe gehört zu einem eigenen Diagramm. Übermitteln Sie die aktuelle Revision. Eine ausgelassene Anordnung bleibt erhalten; eine mitgesendete Anordnung wird atomar mit den Diagrammen gespeichert.

• PATCH Monitordiagramme anordnen

  Speichern Sie Reihenfolge und Bereiche, ohne die Messreihen zu ändern. Übermitteln Sie die aktuelle Revision; parallele Änderungen liefern 409. Automatische Diagramm-IDs bleiben automatisch.

• POST Aktive Gerätemetadaten und Reihen kopieren

  Kopieren Sie aktive Monitoreinstellungen und Reihen ohne Schlüssel oder historische Werte. Die Kopie braucht genügend freie Monitor- und Reihenplätze.

• GET Berechnete Messreihen auflisten

  Formeln für abgeschlossene UTC-Minuten verwenden 1–8 numerische Quellen eines Arbeitsbereichs, höchstens 64 AST-Knoten und Abhängigkeitstiefe 4. Addition und Subtraktion benötigen gleiche Einheiten. Fehlende Quellen und Division durch null bleiben Lücken. Jede neue unveränderliche Revision verbraucht das Datenkontingent des Owners; Wiederholungen sind kostenfrei. Standardmäßig gilt die Formel ab der nächsten Minute; ausdrückliche Nachberechnung umfasst höchstens 24 Stunden. Viewer dürfen lesen; Änderungen benötigen Editor, config:write und Session-CSRF. Ein optionaler Idempotency-Key schützt Wiederholungen und lehnt geänderte Nutzdaten ab. Telemetrieschlüssel dürfen keine berechneten Reihen beschreiben.

• POST Berechnete Messreihe anlegen

  Formeln für abgeschlossene UTC-Minuten verwenden 1–8 numerische Quellen eines Arbeitsbereichs, höchstens 64 AST-Knoten und Abhängigkeitstiefe 4. Addition und Subtraktion benötigen gleiche Einheiten. Fehlende Quellen und Division durch null bleiben Lücken. Jede neue unveränderliche Revision verbraucht das Datenkontingent des Owners; Wiederholungen sind kostenfrei. Standardmäßig gilt die Formel ab der nächsten Minute; ausdrückliche Nachberechnung umfasst höchstens 24 Stunden. Viewer dürfen lesen; Änderungen benötigen Editor, config:write und Session-CSRF. Ein optionaler Idempotency-Key schützt Wiederholungen und lehnt geänderte Nutzdaten ab. Telemetrieschlüssel dürfen keine berechneten Reihen beschreiben.

• GET Textereignisse des eigenen Geräts lesen

  Textereignisse des eigenen Geräts lesen.

• DELETE Gruppe archivieren und Gerätezuordnungen entfernen

  Gruppe archivieren und Gerätezuordnungen entfernen.

• PATCH Eigene Gruppe umbenennen

  Eigene Gruppe umbenennen.

• PATCH Gerätezuordnungen der Gruppe ändern

  Fügen Sie aktive Monitorzuordnungen dieses Arbeitsbereichs hinzu oder entfernen Sie sie. Andere Zuordnungen bleiben erhalten. Dieselbe Änderung ist sicher wiederholbar; doppelte Kennungen oder eine Kennung in beiden Listen sind ungültig.

• GET Öffentlichen Bereitschaftsstatus lesen

  Öffentlichen Bereitschaftsstatus lesen.

• POST Gerätegebundenen Batch mit Text- oder Laufereignissen annehmen

  Höchstens 1.000 Ereignisse und 256 KiB vor und nach Dekompression; jedes Ereignis höchstens 4 KiB, Nachricht höchstens 2 KiB UTF-8. Ereigniskennungen sind kontoweit idempotent. Optionales type-Label steuert Aggregate; ohne type gilt generic. Strukturierte Laufdaten benötigen Freigabe und reservieren normalisierte type-/run_id-Labels.

• POST Gerätekontakt ohne Anfragekörper melden

  Gerätekontakt ohne Anfragekörper melden.

• POST Numerischen Batch atomar annehmen

  Speichern Sie einen Zahlenbatch. Erfolg bestätigt gespeicherte Daten; identische Punktkennungen und Inhalte zählen als Duplikate. Grenzen: 1.000 Einträge und 256 KiB vor und nach Entpackung. identity und gzip sind unterstützt; entpackte Bytes zählen zum Verbrauch. Werte dürfen bis zu 24 Stunden alt oder zwei Minuten voraus sein. Verschiedene Messungen einer Reihe brauchen mindestens eine Sekunde Abstand, auch zu vorhandenen Werten.

• POST Messreihe für Geräteschlüssel wiederholbar registrieren

  Name und Labels identifizieren die Reihe auf dem Gerät des Schlüssels. Andere Labels erstellen eine neue Reihe und verbrauchen Kontingent. Abweichender vorhandener Typ oder Einheit ergibt 409; fremde Geräte sind nicht zugänglich.

• POST Gerätegebundene Boolean- oder Enum-Zustände annehmen

  Boolean-Reihen verlangen JSON-Booleans; Enum-Reihen Zeichenfolgen bis 128 Bytes. Zustände teilen das Ereigniskontingent. Größenlimits gelten vor und nach Dekompression. Aggregatgültigkeit reicht bis zur nächsten Probe, begrenzt durch zweimal das erwartete Intervall und eine Obergrenze zwischen einer und fünf Minuten.

• GET Aktive Schlüsselpräfixe ohne Geheimnisse lesen

  Aktive Schlüsselpräfixe ohne Geheimnisse lesen.

• POST Einmalig sichtbaren gerätegebundenen Schreibschlüssel erstellen

  Wählen Sie ausgewählte Geräte oder alle bestehenden und künftigen Geräte eines Arbeitsbereichs. Nutzen Sie workspace_id, device_scope und device_ids; die Form für ein Gerät verwendet device_id. Secrets werden nur einmal angezeigt.

• POST Lokal gespeicherten Schreibschlüssel wiederholbar übernehmen

  Speichern Sie ein zufälliges mbk_<12 hex>_<64 hex>-Geheimnis lokal, bevor Sie Präfix und SHA-256-Hash übermitteln. Gleiches aktives Gerät und gleicher Hash liefern das Ergebnis erneut; abweichender Inhalt ergibt 409. Kein Klartextgeheimnis wird zurückgegeben.

• DELETE Schreibschlüssel sofort widerrufen

  Schreibschlüssel sofort widerrufen.

• PATCH Name und Gerätezugriff eines API-Schlüssels bearbeiten

  Änderungen gelten sofort ohne Secret-Wechsel. Der Arbeitsbereich bleibt fest. Senden Sie die aktuelle Revision aus GET /keys; veraltete Revisionen liefern 409. Alle Geräte umfasst auch später angelegte Geräte.

• POST Schlüssel atomar widerrufen und ersetzen

  Ersetzen Sie einen Schlüssel und widerrufen Sie sofort den alten. Aktualisieren Sie alle Sender dieses Schlüssels.

• POST Lokal gespeicherten Ersatzschlüssel wiederholbar aktivieren

  Speichern Sie das Ersatzgeheimnis vor der Anfrage. Widerruf des alten Schlüssels, Ersatzaktivierung und Rotationsbeleg erfolgen gemeinsam. Identische Wiederholung liefert das Ergebnis erneut; anderer Hash oder widerrufener Ersatz ergibt einen Konflikt.

• GET Freigegebene aktuelle Werte und Zustände über SSE empfangen

  Browsersitzungen und Maschinencredentials mit telemetry:read können Live-Daten abonnieren. Maschinenzugriff benötigt die unabhängige Laufzeitfreigabe und ist auf zwei Verbindungen je Konto und 64 je API-Prozess begrenzt. Credentials, Konten, Rollen und jede Messreihe werden vor jedem Fünf-Sekunden-Update erneut geprüft. Verbindungen enden nach 15 Minuten. Tokens in URLs werden nicht akzeptiert.

• DELETE Internen Wartungszeitplan entfernen

  Interne einmalige oder wöchentliche Wartung. Messungen und Alarmzustände laufen weiter; Zustellungen werden unterdrückt. IANA-Zeitlücken werden ausgelassen, doppelte Uhrzeiten verwenden die erste Ausführung. Deaktivierte Zeitpläne belegen einen der 20 Plätze. Änderungen erhalten vergangene Zeiten; Gruppenänderungen wirken ab ihrem Zeitpunkt. Öffentliche Hinweise erfordern einen getrennten Entwurf und Veröffentlichungsberechtigung der Statusseite.

• PUT Internen Wartungszeitplan speichern

  Interne einmalige oder wöchentliche Wartung. Messungen und Alarmzustände laufen weiter; Zustellungen werden unterdrückt. IANA-Zeitlücken werden ausgelassen, doppelte Uhrzeiten verwenden die erste Ausführung. Deaktivierte Zeitpläne belegen einen der 20 Plätze. Änderungen erhalten vergangene Zeiten; Gruppenänderungen wirken ab ihrem Zeitpunkt. Öffentliche Hinweise erfordern einen getrennten Entwurf und Veröffentlichungsberechtigung der Statusseite.

• GET Eigene Monitore lesen

  Eigene Monitore lesen.

• POST Monitor mit freigegebenem Typ erstellen

  Monitor mit freigegebenem Typ erstellen.

• POST Geprüfte Aktionen auf ausgewählte Monitore anwenden

  Senden Sie dieselbe Auswahl und Aktions-UUID mit der Vorschauversion und confirmed=true. Bestehende HTTP-Prüfungen, die Ziele verändern können, benötigen zusätzlich actions_confirmed=true. Geänderte Einstellungen, Kontingente oder Auswahl erfordern eine neue Vorschau. Alle ausgewählten Monitore werden gemeinsam geändert oder keiner; Wiederholungen führen die Aktion nicht erneut aus. Intervalle externer Clients und Cron-Zeitpläne verwenden ihre individuellen Einstellungen.

• POST Aktionen für ausgewählte Monitore prüfen

  Wählen Sie 1–100 Monitore eines Arbeitsbereichs sowie Pausieren, Fortsetzen, Gruppenzuordnung oder Erfassungsintervall. Die Vorschau zeigt die genaue Auswahl und den geplanten Tagesverbrauch des Kontos vor und nach der Änderung. Die Prüfung ändert nichts und reserviert keine Kapazität. Ungeeignete Intervalle oder eine erhöhte Kontingentüberschreitung blockieren die gesamte Auswahl.

• DELETE Einen Monitor endgültig löschen

  Nur der Eigentümer des Arbeitsbereichs darf einen Monitor endgültig löschen. Zuerst eine fünf Minuten gültige, an die Konfiguration gebundene Vorschau anfordern; danach preview_id, confirm_deletion: true und einen Idempotency-Key senden. Unbestätigte alte Archivierungsaufrufe werden abgewiesen. Der Monitor wird sofort gesperrt; ein dauerhafter Auftrag entfernt seine Datenbank-, Archiv- und Cachedaten und bereinigt verknüpfte Anzeigen. Den Auftrag bis zum Abschluss abfragen; pausierte Aufträge zeigen einen technischen Fehler und werden automatisch wiederholt. Tageskontingente und Sicherheitszähler bleiben unverändert. Bereits zugestellte Nachrichten und heruntergeladene Dateien können nicht zurückgeholt werden.

• GET Eigenen Monitor und Konfiguration lesen

  Eigenen Monitor und Konfiguration lesen.

• PATCH Monitor mit Revisionsprüfung aktualisieren

  Monitor mit Revisionsprüfung aktualisieren.

• POST HTTP-Erreichbarkeits- und Zertifikatsalarme ausdrücklich speichern

  Legen Sie nur gewählte Alarmvorschläge innerhalb der Kontolimits an. Die Wiederverwendung eines Vorschlags erhält spätere Bearbeitungen.

• GET HTTP-Headernamen ohne geheime Werte lesen

  Liefert Headernamen und den Konfigurationszustand, niemals geheime Werte. Verwenden Sie config_revision bei gleichzeitigen Änderungen.

• PUT Verschlüsselte HTTP-Header speichern oder entfernen

  Höchstens acht gespeicherte Header sind erlaubt. Werte werden mit AES-256-GCM verschlüsselt und an Konto, Monitor, Ursprung und Headernamen gebunden. Verwenden Sie ausdrückliches Entfernen statt eines leeren Ersatzgeheimnisses.

• GET Stündliche Lauf- und Zeitplanübersichten lesen

  Liefert höchstens 168 Stunden lokaler Lauf- und Zeitplandetails. Fehlende Stunden sind unbekannt und keine erfolgreichen Läufe. Eine Zeitplanerwartung gilt nur solange als ausgeblieben, wie kein passender Lauf zugeordnet ist.

• GET Aktuelle Job- und Workflow-Läufe lesen

  Liefert höchstens 100 Läufe aus sieben Tagen. Abschluss kann vor Start eintreffen; started_at bleibt dann bis zum Nachtrag null. Laufzeitgrenzen werden beim Start festgehalten; späterer tatsächlicher Abschluss korrigiert overdue_at.

• GET Serverprofil und Bereitstellungsstatus lesen

  Der versionierte Katalog beschreibt unterstützte Linuxkomponenten. Erkennung aktiviert keine Auswahl. Bereitstellung reserviert Reihenplätze im jeweiligen Konto und erhält vorhandene Historie.

• PUT Serverprofil mit Revisionsprüfung aktualisieren

  Die erwartete Revision verhindert verlorene Änderungen. Vorhandene Komponenten dürfen ihre Identität nicht stillschweigend ändern. Ausdrückliche Zuordnung erhält bekannte Historie; neue Parameter werden asynchron innerhalb der Kontogrenzen bereitgestellt.

• POST Änderung eines Serverprofils prüfen

  Prüfen Sie eine Serverprofiländerung ohne Speicherung. Liefert neue und erhaltene Reihen, nötige Plätze, erwartete Datenmenge und Alarmvorschläge. Nutzen Sie die aktuelle Versionskennung und prüfen Sie die Vorschau vor dem Speichern.

• GET Verfügbare Alarmkanäle und Einrichtungsvoraussetzungen lesen

  Sieben Kanäle mit Verfügbarkeit, Einrichtungsvoraussetzungen, Zielgrenze, öffentlichem VAPID-Schlüssel, Botname und gemeinsamem Testlimit

• GET Eigene benannte Benachrichtigungsziele auflisten

  Ziele einschließlich Verbindungsstatus und letztem Zustellergebnis; keine Zugangsdaten

• POST Benanntes Ziel anlegen oder ein Browser-Push-Abonnement registrieren

  CSRF-geschützt; Idempotency-Key wird unterstützt. Die aktuelle bestätigte Konto-E-Mail-Adresse wird automatisch bestätigt; andere E-Mail-Empfänger benötigen eine einmalige Bestätigung. Telegram erfordert einen privaten /start-Nachweis. Höchstens 20 Ziele pro Konto, zentral konfigurierbar. Beim Webhook wird signing_secret ausschließlich in der ersten Antwort geliefert.

• DELETE Ziel entfernen, Zugangsdaten löschen und wartende Zustellung beenden

  Zugangsdaten sofort gelöscht; beendete Historie bleibt bis zur Retention erhalten

• GET Eigenes Ziel ohne Zugangsdaten lesen

  Eigenes Ziel

• PUT Zielname, Aktivierung oder vollständige Verbindung ändern

  CSRF-geschützt. revision schützt vor parallelen Änderungen. Jede Änderung erhöht die Verbindungsrevision und beendet wartende Nachrichten. E-Mail-Adresse und Telegram-Chat werden über neue Ziele beziehungsweise erneuten Verknüpfungsnachweis geändert.

• POST Test über denselben dauerhaften Zustellablauf einplanen

  CSRF-geschützt und idempotent über Idempotency-Key. Höchstens zehn Tests pro Stunde über alle Ziele zusammen. Ein pausiertes, bestätigtes Ziel kann ausdrücklich getestet werden.

• POST E-Mail-Bestätigung oder zielgebundenen Telegram-Link erzeugen

  Bestätigung eingeplant oder privater Telegram-Link mit zehn Minuten Gültigkeit

• POST Empfänger bestätigt oder beendet eine E-Mail-Verbindung ausdrücklich

  Öffentlicher, ratebegrenzter Endpunkt mit gleichem Origin. Der Bestätigungslink öffnet zunächst /benachrichtigungen/bestaetigen mit Token im Fragment; GET bestätigt nichts. Bestätigungstoken ist einmalig und 24 Stunden gültig. Unsubscribe-Token beendet nur das konkrete Ziel.

• DELETE Eigenen Telegram-Chat trennen

  Trennen entfernt ungenutzte Verbindungscodes und verwirft ausstehende Telegramnachrichten.

• GET Eigene Telegram-Verbindung und Zustellung lesen

  Eigene Telegram-Verbindung und Zustellung lesen.

• PUT Verknüpften Telegram-Kanal aktivieren oder pausieren

  Verknüpften Telegram-Kanal aktivieren oder pausieren.

• POST Einmaligen Telegram-Verbindungslink erstellen

  Der Link gilt zehn Minuten und ersetzt einen zuvor ungenutzten Link dieses Kontos. Erfolgreiches /start aktiviert die Zustellung automatisch und reiht eine Erfolgsnachricht ein.

• POST Telegram-Testnachricht einreihen

  Die Übergabe an den Anbieter ist asynchron. Eingereiht beweist nicht, dass der Nutzer die Nachricht gelesen hat. E-Mail und Telegram teilen das Testnachrichtenbudget.

• GET Gemeinsamen Testverlauf mit Cursor lesen

  Bis zu 50 Tests mit Kanal, Zielname, Status, error_code, attempts, next_attempt_at und next_cursor

• DELETE Einrichtung für ein weiteres Gerät zurücksetzen

  Vorhandene Geräte, Messdaten, Schlüssel und Regeln bleiben erhalten. Setzen Sie die Einrichtung ausdrücklich zurück, bevor Sie ein anderes Gerät einrichten.

• GET Gespeicherte Einrichtung und angenommene Messdaten lesen

  Der Fortschritt enthält Ressourcenkennungen und Zeitpunkte angenommener Daten, niemals gespeicherte Geräteschlüssel. Ein laufender lokaler Prozess allein schließt die Einrichtung nicht ab.

• POST Vorgeschlagenen Alarm speichern und Einrichtung abschließen

  Tatsächlich angenommene Messdaten sind erforderlich. Eine identische Auswahl erzeugt keine zweite Regel. Abschluss ohne Alarm ist eine ausdrückliche Alternative.

• POST Einrichtung nach tatsächlicher Datenannahme abschließen

  Verwenden Sie eine zu dieser Einrichtung gehörende Regel oder setzen Sie ausdrücklich skip_alarm. Vor Abschluss wird die Datenannahme erneut geprüft.

• GET Agentkonfiguration ohne Geheimnisse herunterladen

  Agentkonfiguration ohne Geheimnisse herunterladen.

• POST Einmaligen Einrichtungsschlüssel erstellen oder ausdrücklich rotieren

  Das Geheimnis erscheint einmalig; Antworten sind no-store. Bei Verlust ist ausdrücklich rotate erforderlich. Die Rotation widerruft den vorherigen Schlüssel atomar.

• POST Einmaligen Einrichtungsschlüssel erstellen oder ausdrücklich rotieren

  Das Geheimnis erscheint einmalig; Antworten sind no-store. Bei Verlust ist ausdrücklich rotate erforderlich. Die Rotation widerruft den vorherigen Schlüssel atomar.

• GET Zum API-Stand gehörendes unveränderliches Agentrelease lesen

  Release mit nativer Abnahme auf Linux x64, macOS ARM64 und Windows x64; weitere Architekturen sind nicht nativ abgenommen; 503 bei ausstehender nativer Abnahme oder Veröffentlichung. Betriebssystem-Signaturen sind derzeit nicht verfügbar.

• POST Einrichtungsressourcen atomar wählen oder erstellen

  Ressourcen vorbereiten oder die gespeicherte Auswahl ausdrücklich mit replace_existing=true und ihrer Version expected_updated_at ändern. Unveränderte Auswahlen und identische Wiederholungen erhalten den Fortschritt ohne neue Ressourcen. Änderungen erfolgen atomar, erhalten vorhandene Ressourcen und Schlüssel, übernehmen einen Schlüssel nur für dasselbe Gerät und benötigen ein neues Lebenszeichen und einen Messwert für die resultierenden Reihen. Veraltete Versionen liefern 409 onboarding_changed.

• POST Anonyme Kontaktanfrage übermitteln

  Browserformular desselben Ursprungs; JSON oder URL-encoded, höchstens 64 KiB. Die Formularadresse dient ausschließlich als Reply-To; der Empfänger ist fest. Fünf Versuche je Netzwerkadresse in 15 Minuten, 100 global pro Stunde. Erfolg bestätigt SMTP-Annahme; Fehler erhalten Eingaben. Keine Anhänge oder automatische Antwort.

• GET Veröffentlichte Kontakt- und Rechtstextangaben lesen

  Entwürfe werden nicht ausgeliefert. E-Mail-Adressen bleiben kodiert. Antworten sind no-store; Dokumentversionen sind inhaltsabhängige SHA-256-Werte. Versionsgebundenes öffentliches HTML ist noindex.

• GET Ausschließlich freigegebene öffentliche Daten lesen

  Es werden nur ausdrücklich freigegebene Felder ausgegeben; Entwürfe, Monitoradressen, IPs, Zugangsdaten, Konfigurationen, Logs und interne Alarmtexte bleiben ausgeschlossen. revision, generated_at und fallback kennzeichnen Veröffentlichung und Datenfrische. Ressourcen verwenden dieselben Metadaten. public_api steuert den JSON-Zugriff. Abonnements benötigen eine Anfrage vom selben Ursprung und einen E-Mail-Nachweis; Webhooks zusätzlich eine Empfängerprüfung.

• POST Double-Opt-in-Abonnement anfordern

  Es werden nur ausdrücklich freigegebene Felder ausgegeben; Entwürfe, Monitoradressen, IPs, Zugangsdaten, Konfigurationen, Logs und interne Alarmtexte bleiben ausgeschlossen. revision, generated_at und fallback kennzeichnen Veröffentlichung und Datenfrische. Ressourcen verwenden dieselben Metadaten. public_api steuert den JSON-Zugriff. Abonnements benötigen eine Anfrage vom selben Ursprung und einen E-Mail-Nachweis; Webhooks zusätzlich eine Empfängerprüfung.

• GET Ausschließlich freigegebene öffentliche Daten lesen

  Es werden nur ausdrücklich freigegebene Felder ausgegeben; Entwürfe, Monitoradressen, IPs, Zugangsdaten, Konfigurationen, Logs und interne Alarmtexte bleiben ausgeschlossen. revision, generated_at und fallback kennzeichnen Veröffentlichung und Datenfrische. Ressourcen verwenden dieselben Metadaten. public_api steuert den JSON-Zugriff. Abonnements benötigen eine Anfrage vom selben Ursprung und einen E-Mail-Nachweis; Webhooks zusätzlich eine Empfängerprüfung.

• DELETE Berichtplan entfernen

  Arbeitsbereichs-SLOs verwenden die Gesamtverfügbarkeitsreihe von HTTP-, TCP-, UDP-, DNS-, TLS-, Ping-, Dienst-, Domain- und Browsermonitoren. Unbekannte und unbeobachtete Zeit bleiben ausdrücklich sichtbar; erst die untere Verfügbarkeitsgrenze belegt die Zielerfüllung. Je Arbeitsbereich gelten zehn SLOs und drei Berichtpläne. Kalenderberichte bleiben 90 Tage unveränderlich. E-Mail benötigt die ausdrückliche Freigabe des Owners sowie ein bestätigtes Ziel und teilt das vorhandene Zustellkontingent. Abbrechbare Analysejobs teilen vier globale Plätze und einen je Owner; Arbeitsbereichsgrenzen bleiben verbindlich. Wählen Sie tägliche, wöchentliche oder monatliche Berichte und eine Versandzeit (HH:MM) in einer IANA-Zeitzone. Der Bericht umfasst den vorigen lokalen Kalendertag, die vorige Woche von Montag bis Sonntag oder den vorigen Monat. Die Erstellung startet zur gewählten Zeit; die Zustellung kann später erfolgen. Bei der Zeitumstellung wird eine fehlende Uhrzeit auf die nächste gültige Minute verschoben und eine doppelte Uhrzeit nur einmal verwendet. Die manuelle Erstellung verwendet unabhängig von der Versandzeit den letzten abgeschlossenen Zeitraum.

• PUT Berichtplan ändern

  Arbeitsbereichs-SLOs verwenden die Gesamtverfügbarkeitsreihe von HTTP-, TCP-, UDP-, DNS-, TLS-, Ping-, Dienst-, Domain- und Browsermonitoren. Unbekannte und unbeobachtete Zeit bleiben ausdrücklich sichtbar; erst die untere Verfügbarkeitsgrenze belegt die Zielerfüllung. Je Arbeitsbereich gelten zehn SLOs und drei Berichtpläne. Kalenderberichte bleiben 90 Tage unveränderlich. E-Mail benötigt die ausdrückliche Freigabe des Owners sowie ein bestätigtes Ziel und teilt das vorhandene Zustellkontingent. Abbrechbare Analysejobs teilen vier globale Plätze und einen je Owner; Arbeitsbereichsgrenzen bleiben verbindlich. Wählen Sie tägliche, wöchentliche oder monatliche Berichte und eine Versandzeit (HH:MM) in einer IANA-Zeitzone. Der Bericht umfasst den vorigen lokalen Kalendertag, die vorige Woche von Montag bis Sonntag oder den vorigen Monat. Die Erstellung startet zur gewählten Zeit; die Zustellung kann später erfolgen. Bei der Zeitumstellung wird eine fehlende Uhrzeit auf die nächste gültige Minute verschoben und eine doppelte Uhrzeit nur einmal verwendet. Die manuelle Erstellung verwendet unabhängig von der Versandzeit den letzten abgeschlossenen Zeitraum.

• POST Bericht für die letzte abgeschlossene Periode erstellen

  Arbeitsbereichs-SLOs verwenden die Gesamtverfügbarkeitsreihe von HTTP-, TCP-, UDP-, DNS-, TLS-, Ping-, Dienst-, Domain- und Browsermonitoren. Unbekannte und unbeobachtete Zeit bleiben ausdrücklich sichtbar; erst die untere Verfügbarkeitsgrenze belegt die Zielerfüllung. Je Arbeitsbereich gelten zehn SLOs und drei Berichtpläne. Kalenderberichte bleiben 90 Tage unveränderlich. E-Mail benötigt die ausdrückliche Freigabe des Owners sowie ein bestätigtes Ziel und teilt das vorhandene Zustellkontingent. Abbrechbare Analysejobs teilen vier globale Plätze und einen je Owner; Arbeitsbereichsgrenzen bleiben verbindlich. Wählen Sie tägliche, wöchentliche oder monatliche Berichte und eine Versandzeit (HH:MM) in einer IANA-Zeitzone. Der Bericht umfasst den vorigen lokalen Kalendertag, die vorige Woche von Montag bis Sonntag oder den vorigen Monat. Die Erstellung startet zur gewählten Zeit; die Zustellung kann später erfolgen. Bei der Zeitumstellung wird eine fehlende Uhrzeit auf die nächste gültige Minute verschoben und eine doppelte Uhrzeit nur einmal verwendet. Die manuelle Erstellung verwendet unabhängig von der Versandzeit den letzten abgeschlossenen Zeitraum.

• GET Messreihen des eigenen Geräts lesen

  Messreihen des eigenen Geräts lesen.

• POST Messreihe erstellen

  Messreihe erstellen.

• DELETE Messreihe archivieren und ihre Alarmvorfälle schließen

  Messreihe archivieren und ihre Alarmvorfälle schließen.

• PATCH Reihennamen, Beschreibung oder erwartetes Intervall ändern

  Typ, Einheit und Labels sind nach der Anlage unveränderlich. Nur die dokumentierten veränderbaren Felder können geändert werden.

• GET Messreihenmetadaten lesen

  Metadaten einer berechtigten aktiven Messreihe unabhängig von Listenfiltern oder Cursor-Seiten lesen, einschließlich device_id.

• POST Aktive Reihendaten im selben Gerät kopieren

  Aktive Reihendaten im selben Gerät kopieren.

• PUT Formel einer berechneten Messreihe ändern

  Formeln für abgeschlossene UTC-Minuten verwenden 1–8 numerische Quellen eines Arbeitsbereichs, höchstens 64 AST-Knoten und Abhängigkeitstiefe 4. Addition und Subtraktion benötigen gleiche Einheiten. Fehlende Quellen und Division durch null bleiben Lücken. Jede neue unveränderliche Revision verbraucht das Datenkontingent des Owners; Wiederholungen sind kostenfrei. Standardmäßig gilt die Formel ab der nächsten Minute; ausdrückliche Nachberechnung umfasst höchstens 24 Stunden. Viewer dürfen lesen; Änderungen benötigen Editor, config:write und Session-CSRF. Ein optionaler Idempotency-Key schützt Wiederholungen und lehnt geänderte Nutzdaten ab. Telemetrieschlüssel dürfen keine berechneten Reihen beschreiben.

• GET Vorfälle und Wartung im Reihenzeitraum lesen

  Vorfälle und Wartung im Reihenzeitraum lesen.

• POST Lokale und archivierte Historie abfragen

  Mit prefer_local=true werden sicher vollständige lokale Rohwertdiagramme sofort ohne Auftrag zurückgegeben. Andere Abfragen kombinieren lokale und archivierte Historie über einen asynchronen Auftrag. Diagramme liefern höchstens 1.000 Punkte, Tabellen 2.000 Zeilen je Seite. Auto wählt eine passende Auflösung. Ergebnisse enthalten tatsächliche Auflösung, Quelle, Vollständigkeit, Snapshot und Lücken; Zustandsergebnisse zusätzlich validity_seconds. Ein Tabellencursor ist eine eigene abgeschlossene Auftrags-UUID und erhält die Messzeit-/Punkt-ID-Sortierung. Aufträge und Cursor verfallen nach einem Tag. Höchstens zwei aktive Aufträge je Konto. Originalwertdiagramme erlauben höchstens 1.000 erwartete Punkte. Dichtere Anfragen liefern HTTP 422 mit dem Code invalid_resolution, message_key errors.api.historyChartTooDense sowie message_params.limit und message_params.interval_seconds. Verwenden Sie resolution=auto für ein Diagramm oder mode=table mit resolution=raw für eine paginierte Originalwerttabelle innerhalb der Aufbewahrung.

• GET Letzten numerischen Messwert lesen

  Letzten numerischen Messwert lesen.

• GET Lokale numerische Messwerte oder Aggregate lesen

  raw, minute, quarter_hour und hour wählen lokale Werte oder Aggregate. Numerische Aggregate enthalten count, sum, min, max, last, mean und resetbewussten Zähleranstieg. Kalte Rohdaten und ältere Aggregate werden über Archivaufträge abgefragt.

• GET Letzten Boolean- oder Enum-Zustand lesen

  Letzten Boolean- oder Enum-Zustand lesen.

• GET Lokale Zustandshistorie lesen

  Lokale Zustandshistorie lesen.

• GET Serverprofil-Bereitstellungsauftrag lesen

  Serverprofil-Bereitstellungsauftrag lesen.

• POST Serverprofil-Bereitstellungsauftrag abbrechen

  Bricht ausstehende Bereitstellung ab. Bereits angelegte Reihen und Historie bleiben erhalten; ungenutzte ausstehende Auswahlen geben Reservierungen frei.

• POST Fehlgeschlagenen Serverprofilauftrag wiederholen

  Wiederholt einen eigenen fehlgeschlagenen Auftrag ohne bereits angelegte Reihen zu duplizieren. Verfolgen Sie den gelieferten Zustand, statt unmittelbaren Abschluss anzunehmen.

• DELETE Verfügbarkeits-SLO entfernen

  Arbeitsbereichs-SLOs verwenden die Gesamtverfügbarkeitsreihe von HTTP-, TCP-, UDP-, DNS-, TLS-, Ping-, Dienst-, Domain- und Browsermonitoren. Unbekannte und unbeobachtete Zeit bleiben ausdrücklich sichtbar; erst die untere Verfügbarkeitsgrenze belegt die Zielerfüllung. Je Arbeitsbereich gelten zehn SLOs und drei Berichtpläne. Kalenderberichte bleiben 90 Tage unveränderlich. E-Mail benötigt die ausdrückliche Freigabe des Owners sowie ein bestätigtes Ziel und teilt das vorhandene Zustellkontingent. Abbrechbare Analysejobs teilen vier globale Plätze und einen je Owner; Arbeitsbereichsgrenzen bleiben verbindlich. Wählen Sie tägliche, wöchentliche oder monatliche Berichte und eine Versandzeit (HH:MM) in einer IANA-Zeitzone. Der Bericht umfasst den vorigen lokalen Kalendertag, die vorige Woche von Montag bis Sonntag oder den vorigen Monat. Die Erstellung startet zur gewählten Zeit; die Zustellung kann später erfolgen. Bei der Zeitumstellung wird eine fehlende Uhrzeit auf die nächste gültige Minute verschoben und eine doppelte Uhrzeit nur einmal verwendet. Die manuelle Erstellung verwendet unabhängig von der Versandzeit den letzten abgeschlossenen Zeitraum.

• PUT Verfügbarkeits-SLO ändern

  Arbeitsbereichs-SLOs verwenden die Gesamtverfügbarkeitsreihe von HTTP-, TCP-, UDP-, DNS-, TLS-, Ping-, Dienst-, Domain- und Browsermonitoren. Unbekannte und unbeobachtete Zeit bleiben ausdrücklich sichtbar; erst die untere Verfügbarkeitsgrenze belegt die Zielerfüllung. Je Arbeitsbereich gelten zehn SLOs und drei Berichtpläne. Kalenderberichte bleiben 90 Tage unveränderlich. E-Mail benötigt die ausdrückliche Freigabe des Owners sowie ein bestätigtes Ziel und teilt das vorhandene Zustellkontingent. Abbrechbare Analysejobs teilen vier globale Plätze und einen je Owner; Arbeitsbereichsgrenzen bleiben verbindlich. Wählen Sie tägliche, wöchentliche oder monatliche Berichte und eine Versandzeit (HH:MM) in einer IANA-Zeitzone. Der Bericht umfasst den vorigen lokalen Kalendertag, die vorige Woche von Montag bis Sonntag oder den vorigen Monat. Die Erstellung startet zur gewählten Zeit; die Zustellung kann später erfolgen. Bei der Zeitumstellung wird eine fehlende Uhrzeit auf die nächste gültige Minute verschoben und eine doppelte Uhrzeit nur einmal verwendet. Die manuelle Erstellung verwendet unabhängig von der Versandzeit den letzten abgeschlossenen Zeitraum.

• POST SLO-Auswertung einreihen

  Arbeitsbereichs-SLOs verwenden die Gesamtverfügbarkeitsreihe von HTTP-, TCP-, UDP-, DNS-, TLS-, Ping-, Dienst-, Domain- und Browsermonitoren. Unbekannte und unbeobachtete Zeit bleiben ausdrücklich sichtbar; erst die untere Verfügbarkeitsgrenze belegt die Zielerfüllung. Je Arbeitsbereich gelten zehn SLOs und drei Berichtpläne. Kalenderberichte bleiben 90 Tage unveränderlich. E-Mail benötigt die ausdrückliche Freigabe des Owners sowie ein bestätigtes Ziel und teilt das vorhandene Zustellkontingent. Abbrechbare Analysejobs teilen vier globale Plätze und einen je Owner; Arbeitsbereichsgrenzen bleiben verbindlich. Wählen Sie tägliche, wöchentliche oder monatliche Berichte und eine Versandzeit (HH:MM) in einer IANA-Zeitzone. Der Bericht umfasst den vorigen lokalen Kalendertag, die vorige Woche von Montag bis Sonntag oder den vorigen Monat. Die Erstellung startet zur gewählten Zeit; die Zustellung kann später erfolgen. Bei der Zeitumstellung wird eine fehlende Uhrzeit auf die nächste gültige Minute verschoben und eine doppelte Uhrzeit nur einmal verwendet. Die manuelle Erstellung verwendet unabhängig von der Versandzeit den letzten abgeschlossenen Zeitraum.

• GET Statusseiten und Einladungen auflisten

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• POST Private Statusseite erstellen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• DELETE Öffentliche Auslieferung zurücknehmen oder löschen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• GET Statusseitenentwurf lesen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• PUT Statusseitenentwurf speichern

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• POST Seiteneinladung annehmen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• POST Markenbild prüfen und neu codieren

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• GET Berechtigtes privates Markenbild lesen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• GET Privaten Änderungsnachweis lesen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• GET Betriebszustände eigener Statusdomains lesen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• POST Eindeutige Statusdomain reservieren

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• DELETE Statusdomain-Zuordnung entfernen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• POST Eigentum und Zuordnung der Domain prüfen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• GET Seitenmitglieder auflisten

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• POST Bestehendes Konto für eine Seite einladen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• DELETE Seitenmitglied entfernen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• POST Private Vorschau rendern

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• POST Freigegebene Seitenfassung ausdrücklich veröffentlichen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• GET Vorfalls- und Wartungsentwürfe lesen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• POST Redaktionellen Entwurf speichern

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• POST Freigegebene redaktionelle Meldung veröffentlichen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• POST Redaktionellen Bericht zurücknehmen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• GET Vom Besitzer freigegebene Monitorquellen auflisten

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• PUT Quelle und optionale historische Übernahme freigeben

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• DELETE Freigegebene Quelle zurücknehmen und ihre öffentlichen Projektionen entfernen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• GET Abonnenten- und Versandzustände lesen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• POST Signierten Webhook registrieren und Empfänger prüfen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• DELETE Seitenabonnement entfernen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• POST Signierten Webhook registrieren und Empfänger prüfen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• POST Öffentliche Auslieferung zurücknehmen oder löschen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• GET Versionierten Vorlagenkatalog lesen

  Vorschläge aktivieren Alarme nicht automatisch. HTTP- und Laufvorlagen benötigen außerdem die jeweiligen Funktionsfreigaben.

• POST Vorlage atomar im eigenen Arbeitsbereich anwenden

  Wendet eine Vorlage atomar innerhalb der Kontogrenzen an. Server/NAS v2 reserviert Monitor, Reihen und ausgewählte Alarmplätze und liefert einen fortsetzbaren Auftrag; andere Vorlagen werden sofort angewendet. Wiederholte normalisierte Anfragen liefern den vorhandenen Monitor.

• POST Vorlagenkapazität ohne Reservierung prüfen

  Prüfen Sie Ressourcen und Platzbedarf einer Vorlage, ohne sie anzulegen. Eine Vorschau reserviert keine Plätze; apply prüft den verfügbaren Platz erneut.

• POST Vorlage ohne Ressourcenänderung prüfen

  Prüft Syntax, Version, Konfiguration und Alarmauswahl ohne Ressourcen zu reservieren. Eigentum und Kapazität werden bei plan und apply geprüft.

• GET Kontoweiten Verbrauch und Grenzen lesen

  Mit table=1 wird die vollständige berechtigte Monitor-Verbrauchsliste in gefilterten Cursor-Seiten geliefert. Sort erlaubt zusätzlich items, bytes und planned für absteigende numerische Beiträge. Ohne Pagination bleibt die Antwort die Konto-Verbrauchsübersicht.

• POST Eine Arbeitsbereich-Einladung annehmen

  Arbeitsbereich-Rollen und Verwaltungsscopes werden gemeinsam geprüft. Der Owner trägt gemeinsame Kontingente. Einladungen gelten 48 Stunden und können nur mit der eingeladenen, bestätigten E-Mail-Adresse angenommen werden. Mitgliedschaftsänderungen benötigen eine aktionsgebundene Mailbestätigung; dieselbe Bestätigung mit identischer Nutzlast liefert das gespeicherte Ergebnis ohne erneuten Verbrauch. Der Entzug von Editorrechten widerruft ausgegebene Zugangsschlüssel; Mitgliedsentfernung bricht deren Archivjobs ab. Rechte zur Statusseiten-Veröffentlichung bleiben getrennt.

• GET Eigene Arbeitsbereiche lesen

  Eigene Arbeitsbereiche lesen.

• POST Arbeitsbereich innerhalb der Kontogrenzen erstellen

  external_id macht die gleiche Konto-/Namensanfrage wiederholbar. Dieselbe Kennung mit anderen Eingaben ergibt 409. Wiederholung verbraucht keine zusätzliche Anlagefreigabe.

• DELETE Arbeitsbereich archivieren und enthaltene Schlüssel widerrufen

  Arbeitsbereich archivieren und enthaltene Schlüssel widerrufen.

• PATCH Aktiven eigenen Arbeitsbereich umbenennen

  Aktiven eigenen Arbeitsbereich umbenennen.

• GET Mitgliedschaftsänderungen des Arbeitsbereichs lesen

  Arbeitsbereich-Rollen und Verwaltungsscopes werden gemeinsam geprüft. Der Owner trägt gemeinsame Kontingente. Einladungen gelten 48 Stunden und können nur mit der eingeladenen, bestätigten E-Mail-Adresse angenommen werden. Mitgliedschaftsänderungen benötigen eine aktionsgebundene Mailbestätigung; dieselbe Bestätigung mit identischer Nutzlast liefert das gespeicherte Ergebnis ohne erneuten Verbrauch. Der Entzug von Editorrechten widerruft ausgegebene Zugangsschlüssel; Mitgliedsentfernung bricht deren Archivjobs ab. Rechte zur Statusseiten-Veröffentlichung bleiben getrennt.

• POST Metadaten eines aktiven Arbeitsbereichs kopieren

  Kopiert aktive Gruppen, Geräte und Reihenmetadaten, keine Credentials, Messwerte oder Alarmzustände. Sämtliche kopierten Ressourcen werden gemeinsam gegen die Anlagegrenzen geprüft und verbucht.

• GET Quellen für berechnete Reihen auflisten

  Formeln für abgeschlossene UTC-Minuten verwenden 1–8 numerische Quellen eines Arbeitsbereichs, höchstens 64 AST-Knoten und Abhängigkeitstiefe 4. Addition und Subtraktion benötigen gleiche Einheiten. Fehlende Quellen und Division durch null bleiben Lücken. Jede neue unveränderliche Revision verbraucht das Datenkontingent des Owners; Wiederholungen sind kostenfrei. Standardmäßig gilt die Formel ab der nächsten Minute; ausdrückliche Nachberechnung umfasst höchstens 24 Stunden. Viewer dürfen lesen; Änderungen benötigen Editor, config:write und Session-CSRF. Ein optionaler Idempotency-Key schützt Wiederholungen und lehnt geänderte Nutzdaten ab. Telemetrieschlüssel dürfen keine berechneten Reihen beschreiben.

• GET Aktive Gruppen eines Arbeitsbereichs lesen

  Aktive Gruppen eines Arbeitsbereichs lesen.

• POST Gruppe im eigenen Arbeitsbereich erstellen

  Gruppe im eigenen Arbeitsbereich erstellen.

• POST Ein verifiziertes Konto in einen Arbeitsbereich einladen

  Arbeitsbereich-Rollen und Verwaltungsscopes werden gemeinsam geprüft. Der Owner trägt gemeinsame Kontingente. Einladungen gelten 48 Stunden und können nur mit der eingeladenen, bestätigten E-Mail-Adresse angenommen werden. Mitgliedschaftsänderungen benötigen eine aktionsgebundene Mailbestätigung; dieselbe Bestätigung mit identischer Nutzlast liefert das gespeicherte Ergebnis ohne erneuten Verbrauch. Der Entzug von Editorrechten widerruft ausgegebene Zugangsschlüssel; Mitgliedsentfernung bricht deren Archivjobs ab. Rechte zur Statusseiten-Veröffentlichung bleiben getrennt.

• POST Eine offene Arbeitsbereich-Einladung widerrufen

  Arbeitsbereich-Rollen und Verwaltungsscopes werden gemeinsam geprüft. Der Owner trägt gemeinsame Kontingente. Einladungen gelten 48 Stunden und können nur mit der eingeladenen, bestätigten E-Mail-Adresse angenommen werden. Mitgliedschaftsänderungen benötigen eine aktionsgebundene Mailbestätigung; dieselbe Bestätigung mit identischer Nutzlast liefert das gespeicherte Ergebnis ohne erneuten Verbrauch. Der Entzug von Editorrechten widerruft ausgegebene Zugangsschlüssel; Mitgliedsentfernung bricht deren Archivjobs ab. Rechte zur Statusseiten-Veröffentlichung bleiben getrennt.

• GET Wartungszeitpläne des Arbeitsbereichs lesen

  Interne einmalige oder wöchentliche Wartung. Messungen und Alarmzustände laufen weiter; Zustellungen werden unterdrückt. IANA-Zeitlücken werden ausgelassen, doppelte Uhrzeiten verwenden die erste Ausführung. Deaktivierte Zeitpläne belegen einen der 20 Plätze. Änderungen erhalten vergangene Zeiten; Gruppenänderungen wirken ab ihrem Zeitpunkt. Öffentliche Hinweise erfordern einen getrennten Entwurf und Veröffentlichungsberechtigung der Statusseite.

• POST Internen Wartungszeitplan anlegen

  Interne einmalige oder wöchentliche Wartung. Messungen und Alarmzustände laufen weiter; Zustellungen werden unterdrückt. IANA-Zeitlücken werden ausgelassen, doppelte Uhrzeiten verwenden die erste Ausführung. Deaktivierte Zeitpläne belegen einen der 20 Plätze. Änderungen erhalten vergangene Zeiten; Gruppenänderungen wirken ab ihrem Zeitpunkt. Öffentliche Hinweise erfordern einen getrennten Entwurf und Veröffentlichungsberechtigung der Statusseite.

• GET Mitglieder und Einladungen des Arbeitsbereichs auflisten

  Arbeitsbereich-Rollen und Verwaltungsscopes werden gemeinsam geprüft. Der Owner trägt gemeinsame Kontingente. Einladungen gelten 48 Stunden und können nur mit der eingeladenen, bestätigten E-Mail-Adresse angenommen werden. Mitgliedschaftsänderungen benötigen eine aktionsgebundene Mailbestätigung; dieselbe Bestätigung mit identischer Nutzlast liefert das gespeicherte Ergebnis ohne erneuten Verbrauch. Der Entzug von Editorrechten widerruft ausgegebene Zugangsschlüssel; Mitgliedsentfernung bricht deren Archivjobs ab. Rechte zur Statusseiten-Veröffentlichung bleiben getrennt.

• PATCH Ein Arbeitsbereich-Mitglied ändern oder entfernen

  Arbeitsbereich-Rollen und Verwaltungsscopes werden gemeinsam geprüft. Der Owner trägt gemeinsame Kontingente. Einladungen gelten 48 Stunden und können nur mit der eingeladenen, bestätigten E-Mail-Adresse angenommen werden. Mitgliedschaftsänderungen benötigen eine aktionsgebundene Mailbestätigung; dieselbe Bestätigung mit identischer Nutzlast liefert das gespeicherte Ergebnis ohne erneuten Verbrauch. Der Entzug von Editorrechten widerruft ausgegebene Zugangsschlüssel; Mitgliedsentfernung bricht deren Archivjobs ab. Rechte zur Statusseiten-Veröffentlichung bleiben getrennt.

• GET Berichtpläne auflisten

  Arbeitsbereichs-SLOs verwenden die Gesamtverfügbarkeitsreihe von HTTP-, TCP-, UDP-, DNS-, TLS-, Ping-, Dienst-, Domain- und Browsermonitoren. Unbekannte und unbeobachtete Zeit bleiben ausdrücklich sichtbar; erst die untere Verfügbarkeitsgrenze belegt die Zielerfüllung. Je Arbeitsbereich gelten zehn SLOs und drei Berichtpläne. Kalenderberichte bleiben 90 Tage unveränderlich. E-Mail benötigt die ausdrückliche Freigabe des Owners sowie ein bestätigtes Ziel und teilt das vorhandene Zustellkontingent. Abbrechbare Analysejobs teilen vier globale Plätze und einen je Owner; Arbeitsbereichsgrenzen bleiben verbindlich. Wählen Sie tägliche, wöchentliche oder monatliche Berichte und eine Versandzeit (HH:MM) in einer IANA-Zeitzone. Der Bericht umfasst den vorigen lokalen Kalendertag, die vorige Woche von Montag bis Sonntag oder den vorigen Monat. Die Erstellung startet zur gewählten Zeit; die Zustellung kann später erfolgen. Bei der Zeitumstellung wird eine fehlende Uhrzeit auf die nächste gültige Minute verschoben und eine doppelte Uhrzeit nur einmal verwendet. Die manuelle Erstellung verwendet unabhängig von der Versandzeit den letzten abgeschlossenen Zeitraum.

• POST Berichtplan anlegen

  Arbeitsbereichs-SLOs verwenden die Gesamtverfügbarkeitsreihe von HTTP-, TCP-, UDP-, DNS-, TLS-, Ping-, Dienst-, Domain- und Browsermonitoren. Unbekannte und unbeobachtete Zeit bleiben ausdrücklich sichtbar; erst die untere Verfügbarkeitsgrenze belegt die Zielerfüllung. Je Arbeitsbereich gelten zehn SLOs und drei Berichtpläne. Kalenderberichte bleiben 90 Tage unveränderlich. E-Mail benötigt die ausdrückliche Freigabe des Owners sowie ein bestätigtes Ziel und teilt das vorhandene Zustellkontingent. Abbrechbare Analysejobs teilen vier globale Plätze und einen je Owner; Arbeitsbereichsgrenzen bleiben verbindlich. Wählen Sie tägliche, wöchentliche oder monatliche Berichte und eine Versandzeit (HH:MM) in einer IANA-Zeitzone. Der Bericht umfasst den vorigen lokalen Kalendertag, die vorige Woche von Montag bis Sonntag oder den vorigen Monat. Die Erstellung startet zur gewählten Zeit; die Zustellung kann später erfolgen. Bei der Zeitumstellung wird eine fehlende Uhrzeit auf die nächste gültige Minute verschoben und eine doppelte Uhrzeit nur einmal verwendet. Die manuelle Erstellung verwendet unabhängig von der Versandzeit den letzten abgeschlossenen Zeitraum.

• GET Unveränderliche Arbeitsbereichsberichte auflisten

  Arbeitsbereichs-SLOs verwenden die Gesamtverfügbarkeitsreihe von HTTP-, TCP-, UDP-, DNS-, TLS-, Ping-, Dienst-, Domain- und Browsermonitoren. Unbekannte und unbeobachtete Zeit bleiben ausdrücklich sichtbar; erst die untere Verfügbarkeitsgrenze belegt die Zielerfüllung. Je Arbeitsbereich gelten zehn SLOs und drei Berichtpläne. Kalenderberichte bleiben 90 Tage unveränderlich. E-Mail benötigt die ausdrückliche Freigabe des Owners sowie ein bestätigtes Ziel und teilt das vorhandene Zustellkontingent. Abbrechbare Analysejobs teilen vier globale Plätze und einen je Owner; Arbeitsbereichsgrenzen bleiben verbindlich. Wählen Sie tägliche, wöchentliche oder monatliche Berichte und eine Versandzeit (HH:MM) in einer IANA-Zeitzone. Der Bericht umfasst den vorigen lokalen Kalendertag, die vorige Woche von Montag bis Sonntag oder den vorigen Monat. Die Erstellung startet zur gewählten Zeit; die Zustellung kann später erfolgen. Bei der Zeitumstellung wird eine fehlende Uhrzeit auf die nächste gültige Minute verschoben und eine doppelte Uhrzeit nur einmal verwendet. Die manuelle Erstellung verwendet unabhängig von der Versandzeit den letzten abgeschlossenen Zeitraum.

• GET SLOs des Arbeitsbereichs auflisten

  Arbeitsbereichs-SLOs verwenden die Gesamtverfügbarkeitsreihe von HTTP-, TCP-, UDP-, DNS-, TLS-, Ping-, Dienst-, Domain- und Browsermonitoren. Unbekannte und unbeobachtete Zeit bleiben ausdrücklich sichtbar; erst die untere Verfügbarkeitsgrenze belegt die Zielerfüllung. Je Arbeitsbereich gelten zehn SLOs und drei Berichtpläne. Kalenderberichte bleiben 90 Tage unveränderlich. E-Mail benötigt die ausdrückliche Freigabe des Owners sowie ein bestätigtes Ziel und teilt das vorhandene Zustellkontingent. Abbrechbare Analysejobs teilen vier globale Plätze und einen je Owner; Arbeitsbereichsgrenzen bleiben verbindlich. Wählen Sie tägliche, wöchentliche oder monatliche Berichte und eine Versandzeit (HH:MM) in einer IANA-Zeitzone. Der Bericht umfasst den vorigen lokalen Kalendertag, die vorige Woche von Montag bis Sonntag oder den vorigen Monat. Die Erstellung startet zur gewählten Zeit; die Zustellung kann später erfolgen. Bei der Zeitumstellung wird eine fehlende Uhrzeit auf die nächste gültige Minute verschoben und eine doppelte Uhrzeit nur einmal verwendet. Die manuelle Erstellung verwendet unabhängig von der Versandzeit den letzten abgeschlossenen Zeitraum.

• POST Verfügbarkeits-SLO erstellen

  Arbeitsbereichs-SLOs verwenden die Gesamtverfügbarkeitsreihe von HTTP-, TCP-, UDP-, DNS-, TLS-, Ping-, Dienst-, Domain- und Browsermonitoren. Unbekannte und unbeobachtete Zeit bleiben ausdrücklich sichtbar; erst die untere Verfügbarkeitsgrenze belegt die Zielerfüllung. Je Arbeitsbereich gelten zehn SLOs und drei Berichtpläne. Kalenderberichte bleiben 90 Tage unveränderlich. E-Mail benötigt die ausdrückliche Freigabe des Owners sowie ein bestätigtes Ziel und teilt das vorhandene Zustellkontingent. Abbrechbare Analysejobs teilen vier globale Plätze und einen je Owner; Arbeitsbereichsgrenzen bleiben verbindlich. Wählen Sie tägliche, wöchentliche oder monatliche Berichte und eine Versandzeit (HH:MM) in einer IANA-Zeitzone. Der Bericht umfasst den vorigen lokalen Kalendertag, die vorige Woche von Montag bis Sonntag oder den vorigen Monat. Die Erstellung startet zur gewählten Zeit; die Zustellung kann später erfolgen. Bei der Zeitumstellung wird eine fehlende Uhrzeit auf die nächste gültige Minute verschoben und eine doppelte Uhrzeit nur einmal verwendet. Die manuelle Erstellung verwendet unabhängig von der Versandzeit den letzten abgeschlossenen Zeitraum.

• DELETE MCP-Transportmethode: DELETE

  Der kanonische zustandslose SDK-Transport prüft bei jeder Anfrage ein OAuth- oder Maschinen-MCP-Token. GET mit SSE-Accept-Header liefert 405. DELETE benötigt einen nicht leeren Mcp-Session-Id-Header und bestätigt das Schließen mit 204, ohne das Token zu widerrufen. POST verwendet JSON-Antworten und nimmt MCP-Initialisierung, Benachrichtigungen und Werkzeugmethoden an.

• GET MCP-Transportmethode: GET

  Der kanonische zustandslose SDK-Transport prüft bei jeder Anfrage ein OAuth- oder Maschinen-MCP-Token. GET mit SSE-Accept-Header liefert 405. DELETE benötigt einen nicht leeren Mcp-Session-Id-Header und bestätigt das Schließen mit 204, ohne das Token zu widerrufen. POST verwendet JSON-Antworten und nimmt MCP-Initialisierung, Benachrichtigungen und Werkzeugmethoden an.

• POST MCP-JSON-RPC übermitteln

  Der kanonische zustandslose SDK-Transport prüft bei jeder Anfrage ein OAuth- oder Maschinen-MCP-Token. GET mit SSE-Accept-Header liefert 405. DELETE benötigt einen nicht leeren Mcp-Session-Id-Header und bestätigt das Schließen mit 204, ohne das Token zu widerrufen. POST verwendet JSON-Antworten und nimmt MCP-Initialisierung, Benachrichtigungen und Werkzeugmethoden an.

• GET OAuth-Zustimmung anfordern oder bestätigen

  GET bereitet nach Anmeldung ausdrückliche Browserzustimmung vor. POST bestätigt eine ausstehende Anfrage mit Origin und CSRF. Erforderlich sind PKCE S256, exakt registrierter Rücksprung und kanonische /mcp-Resource. Codes verfallen nach fünf Minuten. Erforderliche Queryparameter kommen genau einmal vor. URIs sind auf 2048 Bytes begrenzt. Der Rücksprung muss einer registrierten HTTPS- oder Loopback-URI exakt entsprechen. Unterstützte Scopes: account:read, config:read, config:write, telemetry:read.

• POST OAuth-Zustimmung anfordern oder bestätigen

  GET bereitet nach Anmeldung ausdrückliche Browserzustimmung vor. POST bestätigt eine ausstehende Anfrage mit Origin und CSRF. Erforderlich sind PKCE S256, exakt registrierter Rücksprung und kanonische /mcp-Resource. Codes verfallen nach fünf Minuten. Der CSRF-Wert wird als Formularfeld csrf_token geliefert und muss dem __Host-mb_csrf-Cookie sowie dieser Sitzung entsprechen. Zustimmung wird einmalig verbraucht; nur approve stellt einen Autorisierungscode aus.

• POST Öffentlichen OAuth-Client registrieren

  Registriert öffentliche Clients mit token_endpoint_auth_method none und ausschließlich authorization_code. HTTPS-Rücksprünge und ausdrücklich erlaubte Loopbackadressen werden geprüft; Registrierung ist begrenzt.

• POST Autorisierungscode gegen MCP-Zugangstoken tauschen

  Akzeptiert application/x-www-form-urlencoded mit authorization_code, client_id, redirect_uri, code_verifier und resource. Codes sind einmalig; Zugriffstokens gelten 15 Minuten, Refreshtokens werden nicht ausgestellt. Alle Formularfelder kommen genau einmal vor. Der Code gilt fünf Minuten, ist einmalig verwendbar und an exakten Client, Rücksprung, Ressource und S256-Verifier gebunden. Das Bearer-Token gilt 900 Sekunden. Es wird kein Refresh-Token ausgestellt.

• PUT telemetry:write für das aktuelle Maschinencredential ausdrücklich freigeben oder abschalten. Verlangt keys:write und erhält die Arbeitsbereichsbindung. Bestehende MCP-Tokens erhalten keine zusätzlichen Scopes; einen neuen Token anfordern.

  telemetry:write für das aktuelle Maschinencredential ausdrücklich freigeben oder abschalten. Verlangt keys:write und erhält die Arbeitsbereichsbindung. Bestehende MCP-Tokens erhalten keine zusätzlichen Scopes; einen neuen Token anfordern.

• POST Zugängliche Messreihen standardmäßig zehn, höchstens 15 Sekunden beobachten. Credential, Scope, Konto und Arbeitsbereich werden alle fünf Sekunden erneut geprüft. Teilt die Live-Grenzen von zwei je Konto und 64 je API-Prozess. Verlangt die Laufzeitfreigabe für Maschinen-Livezugriff.

  Zugängliche Messreihen standardmäßig zehn, höchstens 15 Sekunden beobachten. Credential, Scope, Konto und Arbeitsbereich werden alle fünf Sekunden erneut geprüft. Teilt die Live-Grenzen von zwei je Konto und 64 je API-Prozess. Verlangt die Laufzeitfreigabe für Maschinen-Livezugriff.

• POST Messwerte, Zustände, Ereignisse oder Heartbeats mit ausdrücklich freigegebenem Maschinencredential senden. Nutzt die bestehende Telemetrieprüfung, Kontingente, Deduplizierung und Alarmverarbeitung. Ein konkreter Monitor ist erforderlich. Laufstart und Abschluss verwenden den Ereignisvertrag. Die Laufzeitfreigabe muss aktiviert sein; Ingest-Endpunkte akzeptieren weiterhin nur Geräteschlüssel.

  Messwerte, Zustände, Ereignisse oder Heartbeats mit ausdrücklich freigegebenem Maschinencredential senden. Nutzt die bestehende Telemetrieprüfung, Kontingente, Deduplizierung und Alarmverarbeitung. Ein konkreter Monitor ist erforderlich. Laufstart und Abschluss verwenden den Ereignisvertrag. Die Laufzeitfreigabe muss aktiviert sein; Ingest-Endpunkte akzeptieren weiterhin nur Geräteschlüssel.

• GET Identität Ihres verbundenen Kontos anzeigen.

  Identität Ihres verbundenen Kontos anzeigen.

• GET Aktive Plugin-Verbindungen auflisten.

  Aktive Plugin-Verbindungen auflisten.

• DELETE Eigene Plugin-Verbindung und alle zugehörigen Tokens widerrufen.

  Eigene Plugin-Verbindung und alle zugehörigen Tokens widerrufen.

• POST Browsergebundene Maschinen-OAuth-Anfrage prüfen.

  Browsergebundene Maschinen-OAuth-Anfrage prüfen.

• POST Ausdrücklich gewählte Scopes mit privater Maschinenidentität bestätigen.

  Ausdrücklich gewählte Scopes mit privater Maschinenidentität bestätigen.

• POST Maschinen-OAuth-Anfrage ablehnen.

  Maschinen-OAuth-Anfrage ablehnen.

• POST OAuth-Token oder Refresh-Verbindung widerrufen.

  OAuth-Token oder Refresh-Verbindung widerrufen.

• GET Begrenzte synthetische Prüfer-Testanfragen empfangen.

  Begrenzte synthetische Prüfer-Testanfragen empfangen.

• POST Begrenzte synthetische Prüfer-Testanfragen empfangen.

  Begrenzte synthetische Prüfer-Testanfragen empfangen.

• GET Browsergebundene Maschinen-OAuth-Verbindung starten.

  Browsergebundene Maschinen-OAuth-Verbindung starten.

• POST Browsergebundene Maschinen-OAuth-Verbindung starten.

  Browsergebundene Maschinen-OAuth-Verbindung starten.

• POST Bestätigte Maschinen-OAuth-Verbindung abschließen.

  Bestätigte Maschinen-OAuth-Verbindung abschließen.

• GET Aufbewahrungsfristen lesen (Konto)

  Ganze rollierende 24-Stunden-Tage, mindestens eins. Wirksam ist das Minimum aus Systemobergrenzen, Eigentümerkonto und Monitorvorgaben. Null bedeutet Vererbung. Verkürzungen sperren abgelaufene Daten sofort und starten die physische Bereinigung; pausierte Bereinigungen zeigen den Grund. Abgelaufene Daten kehren nach Verlängerung oder Zurücksetzen nicht zurück. Vorfälle, Zustellhistorien, Berichte und Sicherheitsprotokolle haben eigene Fristen; externe Kopien bleiben unberührt. Änderungen verlangen eine Browsersitzung des Eigentümers, CSRF und einen aktuellen Stand. Kontovorgaben gehören stets zum angemeldeten Nutzer, auch bei Auswahl eines geteilten Arbeitsbereichs. Mitglieder dürfen die Monitorfristen sehen; nur der Arbeitsbereicheigentümer darf sie ändern. Ist die Funktion nicht verfügbar, antworten Änderungen mit HTTP 503; die Leseantwort zeigt, ob Sie die Einstellung ändern dürfen.

• PUT Bestätigte Aufbewahrung speichern (Konto)

  Ganze rollierende 24-Stunden-Tage, mindestens eins. Wirksam ist das Minimum aus Systemobergrenzen, Eigentümerkonto und Monitorvorgaben. Null bedeutet Vererbung. Verkürzungen sperren abgelaufene Daten sofort und starten die physische Bereinigung; pausierte Bereinigungen zeigen den Grund. Abgelaufene Daten kehren nach Verlängerung oder Zurücksetzen nicht zurück. Vorfälle, Zustellhistorien, Berichte und Sicherheitsprotokolle haben eigene Fristen; externe Kopien bleiben unberührt. Änderungen verlangen eine Browsersitzung des Eigentümers, CSRF und einen aktuellen Stand. Kontovorgaben gehören stets zum angemeldeten Nutzer, auch bei Auswahl eines geteilten Arbeitsbereichs. Mitglieder dürfen die Monitorfristen sehen; nur der Arbeitsbereicheigentümer darf sie ändern. Ist die Funktion nicht verfügbar, antworten Änderungen mit HTTP 503; die Leseantwort zeigt, ob Sie die Einstellung ändern dürfen.

• DELETE Geerbte Aufbewahrung wiederherstellen (Konto)

  Ganze rollierende 24-Stunden-Tage, mindestens eins. Wirksam ist das Minimum aus Systemobergrenzen, Eigentümerkonto und Monitorvorgaben. Null bedeutet Vererbung. Verkürzungen sperren abgelaufene Daten sofort und starten die physische Bereinigung; pausierte Bereinigungen zeigen den Grund. Abgelaufene Daten kehren nach Verlängerung oder Zurücksetzen nicht zurück. Vorfälle, Zustellhistorien, Berichte und Sicherheitsprotokolle haben eigene Fristen; externe Kopien bleiben unberührt. Änderungen verlangen eine Browsersitzung des Eigentümers, CSRF und einen aktuellen Stand. Kontovorgaben gehören stets zum angemeldeten Nutzer, auch bei Auswahl eines geteilten Arbeitsbereichs. Mitglieder dürfen die Monitorfristen sehen; nur der Arbeitsbereicheigentümer darf sie ändern. Ist die Funktion nicht verfügbar, antworten Änderungen mit HTTP 503; die Leseantwort zeigt, ob Sie die Einstellung ändern dürfen.

• POST Änderung der Aufbewahrung prüfen (Konto)

  Ganze rollierende 24-Stunden-Tage, mindestens eins. Wirksam ist das Minimum aus Systemobergrenzen, Eigentümerkonto und Monitorvorgaben. Null bedeutet Vererbung. Verkürzungen sperren abgelaufene Daten sofort und starten die physische Bereinigung; pausierte Bereinigungen zeigen den Grund. Abgelaufene Daten kehren nach Verlängerung oder Zurücksetzen nicht zurück. Vorfälle, Zustellhistorien, Berichte und Sicherheitsprotokolle haben eigene Fristen; externe Kopien bleiben unberührt. Änderungen verlangen eine Browsersitzung des Eigentümers, CSRF und einen aktuellen Stand. Kontovorgaben gehören stets zum angemeldeten Nutzer, auch bei Auswahl eines geteilten Arbeitsbereichs. Mitglieder dürfen die Monitorfristen sehen; nur der Arbeitsbereicheigentümer darf sie ändern. Ist die Funktion nicht verfügbar, antworten Änderungen mit HTTP 503; die Leseantwort zeigt, ob Sie die Einstellung ändern dürfen.

• GET Aufbewahrungsfristen lesen (Monitor)

  Ganze rollierende 24-Stunden-Tage, mindestens eins. Wirksam ist das Minimum aus Systemobergrenzen, Eigentümerkonto und Monitorvorgaben. Null bedeutet Vererbung. Verkürzungen sperren abgelaufene Daten sofort und starten die physische Bereinigung; pausierte Bereinigungen zeigen den Grund. Abgelaufene Daten kehren nach Verlängerung oder Zurücksetzen nicht zurück. Vorfälle, Zustellhistorien, Berichte und Sicherheitsprotokolle haben eigene Fristen; externe Kopien bleiben unberührt. Änderungen verlangen eine Browsersitzung des Eigentümers, CSRF und einen aktuellen Stand. Kontovorgaben gehören stets zum angemeldeten Nutzer, auch bei Auswahl eines geteilten Arbeitsbereichs. Mitglieder dürfen die Monitorfristen sehen; nur der Arbeitsbereicheigentümer darf sie ändern. Ist die Funktion nicht verfügbar, antworten Änderungen mit HTTP 503; die Leseantwort zeigt, ob Sie die Einstellung ändern dürfen.

• PUT Bestätigte Aufbewahrung speichern (Monitor)

  Ganze rollierende 24-Stunden-Tage, mindestens eins. Wirksam ist das Minimum aus Systemobergrenzen, Eigentümerkonto und Monitorvorgaben. Null bedeutet Vererbung. Verkürzungen sperren abgelaufene Daten sofort und starten die physische Bereinigung; pausierte Bereinigungen zeigen den Grund. Abgelaufene Daten kehren nach Verlängerung oder Zurücksetzen nicht zurück. Vorfälle, Zustellhistorien, Berichte und Sicherheitsprotokolle haben eigene Fristen; externe Kopien bleiben unberührt. Änderungen verlangen eine Browsersitzung des Eigentümers, CSRF und einen aktuellen Stand. Kontovorgaben gehören stets zum angemeldeten Nutzer, auch bei Auswahl eines geteilten Arbeitsbereichs. Mitglieder dürfen die Monitorfristen sehen; nur der Arbeitsbereicheigentümer darf sie ändern. Ist die Funktion nicht verfügbar, antworten Änderungen mit HTTP 503; die Leseantwort zeigt, ob Sie die Einstellung ändern dürfen.

• DELETE Geerbte Aufbewahrung wiederherstellen (Monitor)

  Ganze rollierende 24-Stunden-Tage, mindestens eins. Wirksam ist das Minimum aus Systemobergrenzen, Eigentümerkonto und Monitorvorgaben. Null bedeutet Vererbung. Verkürzungen sperren abgelaufene Daten sofort und starten die physische Bereinigung; pausierte Bereinigungen zeigen den Grund. Abgelaufene Daten kehren nach Verlängerung oder Zurücksetzen nicht zurück. Vorfälle, Zustellhistorien, Berichte und Sicherheitsprotokolle haben eigene Fristen; externe Kopien bleiben unberührt. Änderungen verlangen eine Browsersitzung des Eigentümers, CSRF und einen aktuellen Stand. Kontovorgaben gehören stets zum angemeldeten Nutzer, auch bei Auswahl eines geteilten Arbeitsbereichs. Mitglieder dürfen die Monitorfristen sehen; nur der Arbeitsbereicheigentümer darf sie ändern. Ist die Funktion nicht verfügbar, antworten Änderungen mit HTTP 503; die Leseantwort zeigt, ob Sie die Einstellung ändern dürfen.

• POST Änderung der Aufbewahrung prüfen (Monitor)

  Ganze rollierende 24-Stunden-Tage, mindestens eins. Wirksam ist das Minimum aus Systemobergrenzen, Eigentümerkonto und Monitorvorgaben. Null bedeutet Vererbung. Verkürzungen sperren abgelaufene Daten sofort und starten die physische Bereinigung; pausierte Bereinigungen zeigen den Grund. Abgelaufene Daten kehren nach Verlängerung oder Zurücksetzen nicht zurück. Vorfälle, Zustellhistorien, Berichte und Sicherheitsprotokolle haben eigene Fristen; externe Kopien bleiben unberührt. Änderungen verlangen eine Browsersitzung des Eigentümers, CSRF und einen aktuellen Stand. Kontovorgaben gehören stets zum angemeldeten Nutzer, auch bei Auswahl eines geteilten Arbeitsbereichs. Mitglieder dürfen die Monitorfristen sehen; nur der Arbeitsbereicheigentümer darf sie ändern. Ist die Funktion nicht verfügbar, antworten Änderungen mit HTTP 503; die Leseantwort zeigt, ob Sie die Einstellung ändern dürfen.

• GET OAuth-Ressourcenmetadaten des Katalog-MCP

  Lesen Sie OAuth-Ressource und unterstützte Rechte für den Katalog-MCP-Endpunkt. Katalogverbindungen erteilen niemals keys:write.

• GET Erfassungseinstellungen lesen

  Lesen Sie die aktuelle Konfiguration und ihre Übernahme durch den Agenten. Prüfintervall und Wiederholungsversand unveränderter Zustände bleiben getrennt. Eigene Definitionen enthalten nur deklarierte Feldtypen und Quellenkennungen, niemals Befehle oder Zugangsdaten.

• PATCH Erfassungseinstellungen ändern

  Verwendet stabile Quellenkennungen. Geänderte Felder werden in der Reihenfolge der Serverannahme übernommen; andere Felder und Messhistorien bleiben erhalten. Wiederholen Sie nach einer verlorenen Antwort dieselbe operation_id und denselben Inhalt. Namen, Beschreibungen, Aktivierungen und Prüfintervalle werden synchronisiert. Programme und Argumente bleiben in der lokal freigegebenen Richtlinie.

• POST Erfassungsänderungen prüfen

  Verwendet stabile Quellenkennungen. Geänderte Felder werden in der Reihenfolge der Serverannahme übernommen; andere Felder und Messhistorien bleiben erhalten. Wiederholen Sie nach einer verlorenen Antwort dieselbe operation_id und denselben Inhalt. Namen, Beschreibungen, Aktivierungen und Prüfintervalle werden synchronisiert. Programme und Argumente bleiben in der lokal freigegebenen Richtlinie.

• GET Erfassungsrevisionen empfangen

  Ein ausgehender HTTPS-Ereignisstrom signalisiert neue Revisionen. Lesen Sie nach Ereignissen oder Wiederverbindung den aktuellen Stand; Last-Event-ID ist kein Wiedergabeprotokoll. CLI- und MCP-Zugänge erhalten eine einzelne JSON-Revision für begrenzte Abfragen. Fragen Sie ohne Ereignisverbindung alle fünf Sekunden ab und beachten Sie den Fehler-Backoff.

• GET Gebundene Agentkonfiguration lesen

  Lesen Sie die aktuelle Konfiguration und ihre Übernahme durch den Agenten. Prüfintervall und Wiederholungsversand unveränderter Zustände bleiben getrennt. Eigene Definitionen enthalten nur deklarierte Feldtypen und Quellenkennungen, niemals Befehle oder Zugangsdaten.

• PATCH Lokale Änderungen synchronisieren

  Verwendet stabile Quellenkennungen. Geänderte Felder werden in der Reihenfolge der Serverannahme übernommen; andere Felder und Messhistorien bleiben erhalten. Wiederholen Sie nach einer verlorenen Antwort dieselbe operation_id und denselben Inhalt. Namen, Beschreibungen, Aktivierungen und Prüfintervalle werden synchronisiert. Programme und Argumente bleiben in der lokal freigegebenen Richtlinie.

• POST Prüfungen und übernommene Konfiguration melden

  Lesen Sie die aktuelle Konfiguration und ihre Übernahme durch den Agenten. Prüfintervall und Wiederholungsversand unveränderter Zustände bleiben getrennt. Eigene Definitionen enthalten nur deklarierte Feldtypen und Quellenkennungen, niemals Befehle oder Zugangsdaten.

• GET Gebundene Agentrevisionen empfangen

  Ein ausgehender HTTPS-Ereignisstrom signalisiert neue Revisionen. Lesen Sie nach Ereignissen oder Wiederverbindung den aktuellen Stand; Last-Event-ID ist kein Wiedergabeprotokoll. CLI- und MCP-Zugänge erhalten eine einzelne JSON-Revision für begrenzte Abfragen. Fragen Sie ohne Ereignisverbindung alle fünf Sekunden ab und beachten Sie den Fehler-Backoff.

• POST Betroffene Verknüpfungen vor der Monitorlöschung prüfen

  Nur der Eigentümer des Arbeitsbereichs darf einen Monitor endgültig löschen. Zuerst eine fünf Minuten gültige, an die Konfiguration gebundene Vorschau anfordern; danach preview_id, confirm_deletion: true und einen Idempotency-Key senden. Unbestätigte alte Archivierungsaufrufe werden abgewiesen. Der Monitor wird sofort gesperrt; ein dauerhafter Auftrag entfernt seine Datenbank-, Archiv- und Cachedaten und bereinigt verknüpfte Anzeigen. Den Auftrag bis zum Abschluss abfragen; pausierte Aufträge zeigen einen technischen Fehler und werden automatisch wiederholt. Tageskontingente und Sicherheitszähler bleiben unverändert. Bereits zugestellte Nachrichten und heruntergeladene Dateien können nicht zurückgeholt werden.

• GET Eigene Monitorlöschaufträge auflisten

  Nur der Eigentümer des Arbeitsbereichs darf einen Monitor endgültig löschen. Zuerst eine fünf Minuten gültige, an die Konfiguration gebundene Vorschau anfordern; danach preview_id, confirm_deletion: true und einen Idempotency-Key senden. Unbestätigte alte Archivierungsaufrufe werden abgewiesen. Der Monitor wird sofort gesperrt; ein dauerhafter Auftrag entfernt seine Datenbank-, Archiv- und Cachedaten und bereinigt verknüpfte Anzeigen. Den Auftrag bis zum Abschluss abfragen; pausierte Aufträge zeigen einen technischen Fehler und werden automatisch wiederholt. Tageskontingente und Sicherheitszähler bleiben unverändert. Bereits zugestellte Nachrichten und heruntergeladene Dateien können nicht zurückgeholt werden.

• GET Einen Monitorlöschauftrag lesen

  Nur der Eigentümer des Arbeitsbereichs darf einen Monitor endgültig löschen. Zuerst eine fünf Minuten gültige, an die Konfiguration gebundene Vorschau anfordern; danach preview_id, confirm_deletion: true und einen Idempotency-Key senden. Unbestätigte alte Archivierungsaufrufe werden abgewiesen. Der Monitor wird sofort gesperrt; ein dauerhafter Auftrag entfernt seine Datenbank-, Archiv- und Cachedaten und bereinigt verknüpfte Anzeigen. Den Auftrag bis zum Abschluss abfragen; pausierte Aufträge zeigen einen technischen Fehler und werden automatisch wiederholt. Tageskontingente und Sicherheitszähler bleiben unverändert. Bereits zugestellte Nachrichten und heruntergeladene Dateien können nicht zurückgeholt werden.

• GET Numerische Originalmesswerte live übertragen

  Erhalten Sie einen Anfangsstand und dauerhaft gespeicherte numerische Messpunkte über Server-Sent Events. Es werden ausschließlich tatsächlich gespeicherte Werte geliefert. Punktkennungen erlauben die Deduplizierung; der kontogebundene Cursor setzt Unterbrechungen zwanzig Minuten lang fort. Abgelaufene Cursor und korrigierte berechnete Reihen erneuern das gewählte Fenster. Ein Frame enthält höchstens 1.000 Punkte und 256 KiB. Sitzung, Arbeitsbereichs- und Reihenrechte sowie Kontingente werden vor jedem Frame erneut geprüft.

• GET Offene Vorfälle zählen

  Alle noch nicht entwarnten Vorfälle im gewählten Arbeitsbereich zählen, einschließlich bestätigter und stummgeschalteter Vorfälle. Es gelten dieselben Leserechte wie für die Vorfallliste. Pagination, Suche und Zeitraumfilter beeinflussen die Anzahl nicht.

• POST Eine Besitzchallenge für das lokale Plugin erstellen

  Eine fünfminütige Challenge für das aktuelle Maschinenkonto, den Recovery-Key, das Verwaltungscredential und den registrierten Client erstellen. Es werden keine Rechte erteilt.

• POST Die lokale Plugin-Identität authentifizieren

  Eine signierte Besitzchallenge prüfen. Initialer Zugriff ist auf Katalogleserechte beschränkt; widerrufene oder abgelaufene Verbindungen verlangen Browserfreigabe. Hier zurückgegebene Tokens sind privater Helferzustand und dürfen nie im Chat erscheinen.

• GET Die aktuelle Plugin-Verbindung lesen

  Die durch diesen Katalog-OAuth-Token bestimmte Verbindung, ihre Rechte, Berechtigungsrevision und E-Mail-Bestätigung lesen.

• POST E-Mail-Bestätigung oder Plugin-Rechte anfordern

  Eine zehnminütige Browseranfrage für die eigene Verbindung dieses Tokens erstellen. E-Mail-Bestätigung führt Konten nie zusammen; Rechtevorschläge sind auf die fünf Katalogrechte begrenzt und können sich nicht selbst freigeben.

• GET Den Status einer eigenen Plugin-Anfrage lesen

  Eine eigene Anfrage und ihren aktuell wirksamen Verbindungszustand lesen. Anfragen anderer Verbindungen lassen sich nicht abfragen.

• PUT Plugin-Berechtigungen im Browser ändern

  Im Browser ausgewählte Katalogrechte mit CSRF-Schutz und erwarteter Revision anwenden. Ältere Zugangstokens werden ungültig; eine leere Rechteliste widerruft die Verbindung. Arbeitsbereichsrollen bleiben unverändert.

• GET Eine Plugin-Browserfreigabe öffnen

  Aktuelle und vorgeschlagene Rechte oder einen E-Mail-Claim anzeigen. Besitzer unbestätigter lokaler Maschinenkonten laden vor der separaten Freigabe die einmalige signierte Datei des Helfers hoch. Die Datei gilt zehn Minuten und der Bestätigungskontext fünf Minuten.

• POST Eine Plugin-Anfrage bestätigen oder ablehnen

  Die signierte Datei prüfen oder die gebundene Anfrage separat vollständig, teilweise oder gar nicht freigeben. E-Mail-Bestätigung verwendet einen dreißigminütigen Link; belegte Adressen werden erst nach Nachweis des Adressbesitzes offengelegt.

• POST Lokale Diagrammvorschauen gesammelt lesen

  Bis zu 16 numerische oder Zustandsreihen dieses Monitors für ein gemeinsames Zeitfenster lesen. Jede Reihe liefert ein lokales Ergebnis oder zeigt an, dass eine separate Historienabfrage erforderlich ist. Lokale Vorschauen umfassen höchstens 24 Stunden und 1.000 Anzeigepunkte je Reihe; die Antwort ist auf 4 MiB begrenzt. Leserechte genügen. Diese Anfrage legt keine Archivaufträge an.

• GET Verfügbare Prüfstandorte

  Zeigt berechtigte, erreichbare Prüfstandorte und freigegebene Checktypen. Nicht verfügbare oder deaktivierte Standorte fehlen.

• GET Prüfergebnisse je Standort

  Lesen Sie sieben Tage HTTP-, Netzwerk- und Browserprüfungen mit stabiler Cursor-Paginierung sowie Ergebnis-, Standort- und Zeitraumfiltern. Overview und history liefern kompakte Zeilen ohne Diagnoseinhalte oder Zähler; laden Sie Zähler unabhängig mit dem Seiten-Snapshot und vollständige Diagnosen mit view=detail. Aktuelle Zustände berücksichtigen alle ausgewählten Standorte und die Frische der Beobachtungen. summary_only=1 liefert nur aktuelle Zustände. Fehlende historische Angaben bleiben unbekannt.

• GET API: Belegungsstatus der Prüfgeheimnisse lesen

  Lesen Sie die konfigurierten Geheimnisnamen und ob ein Wert hinterlegt ist. Geheimniswerte können nicht gelesen werden. Ein Zielwechsel entfernt zugehörige Geheimnisse; Änderungen an Schwellen und gewählten Messgrößen erhalten sie.

• PUT API: Prüfgeheimnisse schreiben

  Speichern oder entfernen Sie benannte Werte, auf die die Prüfkonfiguration verweist. Übermitteln Sie expected_revision, um gleichzeitige Änderungen abzuweisen. Die Antwort enthält ausschließlich die neue Konfigurationsrevision. Werte werden nicht zurückgegeben; laufende Prüfungen werden abgebrochen und folgende Prüfungen verwenden die neue Revision.

• POST Erwartete Ausführungen anzeigen

  Prüft einen Jobzeitplan ohne Speicherung und liefert die nächsten zehn erwarteten UTC-Zeitpunkte. Die Vorschau legt weder Monitor noch Alarme an.

• GET Monitorzeitplan lesen

  Liest gespeicherten Zeitplan, nächste zehn erwartete Ausführungen, angenommenes Lebenszeichen und Anzahl laufender beziehungsweise überfälliger Läufe. Pausierte und ereignisbasierte Monitore haben keine anstehenden Ausführungen. Zähler verwenden die verfügbaren aufbewahrten Laufdetails.

• POST API: Prüfeinstellungen und Verbrauch vorab prüfen

  Prüfen Sie eine Prüfkonfiguration, berechtigte gesunde Standorte und auswählbare Messreihen vor dem Anlegen oder Ändern eines Monitors. Die Vorschau zeigt neue und erhaltene Reihen, freie Kontoplätze sowie die geschätzten Prüfungen je Minute. Sie legt keine Ressourcen an und reserviert kein Kontingent. Beim Anlegen werden aktuelle Rechte und Kapazität erneut geprüft; Datenobjekte je Tag sind eine Obergrenze und kein tatsächlicher Verbrauch. Ein ausgefallener Standort oder gesperrter Prüftyp erzeugt keine erfundene erfolgreiche Vorschau.

• GET Alarmvorschläge für Prüfungen lesen

  Verfügbare Vorschläge und bestehende Regelkennungen für die aktuell ausgewählten Messgrößen lesen. Das Lesen legt keine Regeln an.

• POST Ausgewählte Alarmvorschläge für Prüfungen speichern

  Ausdrücklich ausgewählte Kennungen für die aktuelle Monitorrevision speichern. Wiederholungen verwenden bestehende aktive Regeln und erhalten eigene Änderungen. Die globale Verfügbarkeitsregel berücksichtigt das eingestellte Standortquorum und die Bestätigungsanzahl.

• POST Monitor-Test starten

  Starten Sie einen Test am gewählten Standort ohne Änderung der Messhistorie oder Alarmbestätigungen. Dieselbe Anfragekennung liefert den ursprünglichen Auftrag.

• GET Monitor-Test lesen

  Lesen Sie den berechtigten Teststatus, Kontingentpausen und das private Diagnoseergebnis. Ein fehlendes Ergebnis bestätigt keine Erreichbarkeit des Ziels.

• POST Monitor-Test abbrechen

  Brechen Sie einen eigenen Test ab und entwerten Sie seine Ausführungsfreigabe. Wiederholter Abbruch startet keinen Test und ändert den normalen Monitorzeitplan nicht.

• POST API: Check-Einrichtung fortsetzen oder abbrechen

  Ausstehende Messreihen eines Checkmonitors erneut anlegen oder abbrechen. Abbruch gibt ausstehende Plätze frei, pausiert den Monitor und erhält vorhandene Historie. Wiederholen reserviert die Plätze anhand der gespeicherten Konfiguration erneut; das Fortsetzen des Monitors bleibt eine ausdrückliche Aktion.

• GET Prüfergebnisse je Standort

  Listen Sie die noch nicht abgelaufenen privaten Browseraufzeichnungen dieses Monitors mit Filtern und Snapshot-Paginierung auf.

• GET Prüfergebnisse je Standort

  Laden Sie eine private verschlüsselte Aufzeichnung nach erneuter Berechtigungsprüfung herunter.

• DELETE Monitor-Test starten

  Löschen Sie eine Browseraufzeichnung und geben Sie ihren Speicher frei. Wiederholte Ergebnisse stellen gelöschte Aufzeichnungen nicht wieder her.

• POST Monitor-Test starten

  Bestätigen Sie ausdrücklich einen Screenshot als visuelle Referenz für das aktuelle Ziel und die Darstellung. Die Bestätigung verlängert dessen Aufbewahrung nicht.

• GET Gesamtverfügbarkeitsquelle des Monitors lesen

  HTTP- sowie TCP-, UDP-, DNS-, TLS-, Ping-, Dienst-, Domain- und Browsermonitore verwenden eine Gesamtverfügbarkeitsreihe je Monitor. Bei mehreren Prüfstandorten folgt diese der eingestellten Bestätigung und Standortregel (ein Standort, alle oder Quorum). Zeiten einzelner Standorte oder Engines werden nicht addiert. Der Katalog enthält aktive Monitore mit aktivierter Verfügbarkeitserfassung; die einzelne Quelle macht auch erhaltene Historie bei deaktivierter Erfassung zugänglich. Unbekannte, pausierte und unbeobachtete Zeit zählen niemals als bestätigte Verfügbarkeit. SLOs und Berichte verwenden dieselbe Quelle und behalten ihre getrennte Wartungsberechnung.

• GET Verfügbarkeitsquellen eines Arbeitsbereichs auflisten

  HTTP- sowie TCP-, UDP-, DNS-, TLS-, Ping-, Dienst-, Domain- und Browsermonitore verwenden eine Gesamtverfügbarkeitsreihe je Monitor. Bei mehreren Prüfstandorten folgt diese der eingestellten Bestätigung und Standortregel (ein Standort, alle oder Quorum). Zeiten einzelner Standorte oder Engines werden nicht addiert. Der Katalog enthält aktive Monitore mit aktivierter Verfügbarkeitserfassung; die einzelne Quelle macht auch erhaltene Historie bei deaktivierter Erfassung zugänglich. Unbekannte, pausierte und unbeobachtete Zeit zählen niemals als bestätigte Verfügbarkeit. SLOs und Berichte verwenden dieselbe Quelle und behalten ihre getrennte Wartungsberechnung.

• POST Monitorverfügbarkeit auswerten

  Wertet die letzten 90 Tage und Zeiträume von 24 Stunden, 7, 30 und 90 Tagen mit der Gesamtverfügbarkeitsreihe des Monitors aus. Kalendertage verwenden die Zeitzone des anfragenden Kontos. Unbekannte, pausierte und fehlende Zeit ist keine bestätigte Verfügbarkeit. Bestehende Historienkapazität und Aufbewahrung gelten. Passende laufende Jobs oder höchstens fünf Minuten alte Ergebnisse werden wiederverwendet; den zurückgegebenen Archivjob bis zum Abschluss abfragen.

• POST Ausstehende Statistikbelege abrufen

  Browseroperation für ein bestätigtes reguläres menschliches Konto. Erfordert die bestehende Session, einen Request vom selben Ursprung und CSRF-Token. Liefert höchstens drei bestätigte Erstereignisse mit einer Zustelllease von 90 Sekunden. Bei Wiederholung dieselbe Event-ID verwenden. Keine historischen Ereignisse oder Maschinenzugriffe. Die Zustellung kann innerhalb von sieben Tagen nach dem Ereignis beginnen; Wiederholungen enden 47 Stunden nach dem ersten Versuch innerhalb der Duplikatsperre des Collectors.

• POST Angenommenen Statistikbeleg bestätigen

  ID und Lease aus dem Abruf in derselben Browser-Session verwenden. Erst bestätigen, wenn der Collector stored, duplicate oder filtered meldet. Wiederholte Bestätigungen sind idempotent. Produktive Belege im Diagnosemodus nicht bestätigen. Die Lease bleibt privat; nur die zufällige Event-ID gelangt zum Collector.

• POST Monitorentwurf testen

  Führen Sie die eingerichtete Prüfung einmal an einem ausgewählten berechtigten Standort aus, ohne Monitor, Messreihen oder Alarme anzulegen. Verwenden Sie nach einer ungewissen Antwort dieselbe request_id. Geschützte Zugangsdaten und private Ergebnisse verfallen nach 15 Minuten. Browser- und Mailaktionen verlangen actions_confirmed; Browseraufzeichnungen sind deaktiviert, visuelle Referenzen benötigen einen gespeicherten Monitor. Ausführungen teilen die regulären Netzwerk-/Browserkontingente.

• GET Ergebnis eines Entwurfstests lesen

  Lesen Sie Ihren privaten Entwurfstest im berechtigten Arbeitsbereich vor seinem Ablauf nach 15 Minuten. Ausstehende und laufende Prüfungen, unbekannte Ergebnisse und bestätigte Zielfehler bleiben unterscheidbar.

• POST Entwurfstest abbrechen

  Brechen Sie Ihren eigenen aktiven Entwurfstest ab. Wiederholter Abbruch ist sicher. Laufende Browserzeit bleibt verbucht; verspätete Ergebnisse werden abgewiesen.

• GET Website-Favicon lesen

  Liefert das öffentliche Favicon dieses HTTP- oder Browser-Monitors als Bild. Erfordert dieselben Leserechte im Arbeitsbereich wie der Monitor. Ist kein Icon verfügbar, bleibt die Antwort leer.

• GET Monitorbenachrichtigungen lesen

  Lesen Sie die gespeicherten Ausfall-, Ablauf- und Nachrichteneinstellungen.

• PUT Monitorbenachrichtigungen speichern

  Speichern Sie mit den aktuellen Konfigurations- und Benachrichtigungsrevisionen. Verwaltete Alarmregeln und Ressourcenlimits werden gemeinsam geprüft.

• GET Eskalationsrichtlinien auflisten

  Listen Sie Ihre wiederverwendbaren Benachrichtigungsrichtlinien auf.

• POST Eskalationsrichtlinie anlegen

  Wählen Sie bis zu fünf Stufen mit bestätigten Zielen. Die erste Stufe beginnt sofort; weitere Verzögerungen steigen bis höchstens 24 Stunden.

• PUT Eskalationsrichtlinie ändern

  Verwenden Sie die aktuelle Revision. Änderungen gelten für neue Vorfälle.

• DELETE Eskalationsrichtlinie löschen

  Von Monitoren verwendete Richtlinien können nicht gelöscht werden.

• GET Verfügbare Benachrichtigungsoptionen lesen

  Lesen Sie bestätigte Ziele und Richtlinien für den gewählten Arbeitsbereich.

• POST Einmaligen Server-Installationscode erstellen

  Im Browser freigegebener Zehn-Minuten-Code für diesen Arbeitsbereich und das gewählte Profil. Erst beim Einlösen entsteht ein Monitor; Bearbeitungsrechte sind erforderlich. Gespeichert wird nur der Codehash.

• GET Fortschritt der automatischen Servereinrichtung lesen

  Meldet den Eingang des ersten Lebenszeichens und ausgewählter Messwerte nach der Verbindung. Der ausstellende Browser kann den Fortschritt auch nach Ablauf des Codes lesen.

• DELETE Unbenutzten Installationscode widerrufen

  Widerruft einen unbenutzten Code. Bereits verbundene Server und ihre Geräteschlüssel werden über die vorhandenen Monitor- und Schlüsselschnittstellen verwaltet.

• POST Server mit Installationscode verbinden

  Legt den gebundenen Server, Profil, Gruppen und einen Geräteschlüssel aus dem lokal erzeugten Schlüsselhash atomar an oder verbindet sie. Identische Anfragen können sicher fortgesetzt werden; der private Geräteschlüssel kann eine gespeicherte Verbindung nach Ablauf des Codes wiederaufnehmen.

• GET Einrichtungsskript für Linux/macOS laden

  Ermittelt beim Ausführen den neuesten freigegebenen nativen Agenten. Bindet Programm-URLs und SHA-256-Prüfungen an dieselbe signaturgeprüfte Version; der Agent prüft sein signiertes Manifest vor der Einrichtung. Der Code wird als lokales Argument übergeben.

• GET Einrichtungsskript für Windows laden

  PowerShell-Einstieg für den neuesten freigegebenen Windows-Agenten. Erkennt die Architektur, prüft Downloads und startet automatische Verbindung sowie native Dienstinstallation. Eine Administratorbestätigung kann erforderlich sein.

• GET Signierten Webhook registrieren und Empfänger prüfen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• PUT Signierten Webhook registrieren und Empfänger prüfen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• GET Signierten Webhook registrieren und Empfänger prüfen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• GET Signierten Webhook registrieren und Empfänger prüfen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• PUT Signierten Webhook registrieren und Empfänger prüfen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• GET Vorfalls- und Wartungsentwürfe lesen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• GET Signierten Webhook registrieren und Empfänger prüfen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• POST Signierten Webhook registrieren und Empfänger prüfen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• POST Signierten Webhook registrieren und Empfänger prüfen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• GET Signierten Webhook registrieren und Empfänger prüfen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• POST Signierten Webhook registrieren und Empfänger prüfen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• POST Signierten Webhook registrieren und Empfänger prüfen

  Authentifizierte Seitenverwaltung mit aktiver Sitzung, Eigentums-, Seitenrollen- und CSRF-Prüfung. Quellen, Mitglieder, Domains, Versandregeln und die Rücknahme der ganzen Seite benötigen den Besitzer. Redakteure speichern Entwürfe; Herausgeber veröffentlichen freigegebene Inhalte. version erkennt parallele Änderungen. Veröffentlichung und Rücknahme sind erst nach Bestätigung der passenden Veröffentlichungsfassung durch die öffentliche Auslieferung abgeschlossen.

• GET Persönliche Listenreihenfolge lesen

  Persönliche Listenreihenfolge des angemeldeten Benutzers in diesem Arbeitsbereich. Eigentümer, Bearbeiter und Betrachter können ihre eigene Reihenfolge ändern. Nur Browsersitzungen; Änderungen benötigen CSRF und einen Idempotency-Key. Die manuelle Sortierung erhält die relative Reihenfolge der übrigen Einträge; neue Einträge werden angehängt, gelöschte oder neu zugeordnete Einträge verlieren ihre Position.

• DELETE Persönliche Listenreihenfolge zurücksetzen

  Persönliche Listenreihenfolge des angemeldeten Benutzers in diesem Arbeitsbereich. Eigentümer, Bearbeiter und Betrachter können ihre eigene Reihenfolge ändern. Nur Browsersitzungen; Änderungen benötigen CSRF und einen Idempotency-Key. Die manuelle Sortierung erhält die relative Reihenfolge der übrigen Einträge; neue Einträge werden angehängt, gelöschte oder neu zugeordnete Einträge verlieren ihre Position.

• POST Eintrag in der persönlichen Liste verschieben

  Persönliche Listenreihenfolge des angemeldeten Benutzers in diesem Arbeitsbereich. Eigentümer, Bearbeiter und Betrachter können ihre eigene Reihenfolge ändern. Nur Browsersitzungen; Änderungen benötigen CSRF und einen Idempotency-Key. Die manuelle Sortierung erhält die relative Reihenfolge der übrigen Einträge; neue Einträge werden angehängt, gelöschte oder neu zugeordnete Einträge verlieren ihre Position.

• GET Zuständigkeit und interne Notizen lesen

  Lesen Sie die Zuständigkeit und den tatsächlichen Bestätiger. Interne Notizen haben Cursorseiten mit 50 Einträgen. Nur Mitglieder des Arbeitsbereichs können sie lesen.

• PATCH Vorfall zuweisen

  Weisen Sie den Vorfall mit der aktuellen Zuständigkeitsrevision und einer Vorgangs-UUID einem aktiven Owner oder Editor zu. Eine leere ID entfernt die Zuweisung.

• POST Interne Vorfallnotiz hinzufügen

  Editoren können mit einer Vorgangs-UUID Textnotizen bis 4 KiB anlegen. Limits je Owner-Konto: 10 pro Minute, 100 je UTC-Tag und 1.000 je Vorfall einschließlich gelöschter Notizen. Dieselbe UUID liefert dieselbe Notiz. Notizen werden nie automatisch veröffentlicht oder versendet.

• DELETE Interne Vorfallnotiz löschen

  Ein Editor kann eigene Notizen löschen; der Owner kann alle Notizen dieses Arbeitsbereichs löschen. Wiederholtes Löschen gelingt. Der Notiztext wird entfernt; Metadaten für Limits bleiben bis zur Vorfall- oder Kontolöschung erhalten.

• GET API: Eigene Hintergrundaufträge auflisten

  Listen Sie eigene CSV-Exporte, fortgesetzte Historienabfragen und aktuelle Verfügbarkeitsauswertungen oder Berichte eines Arbeitsbereichs auf. Mitgliedschaft und Aufbewahrung gelten auch für Ergebnisse.

• GET Aktuelle autorisierte Serverübersichten und entfernte Kennungen.

  Lesen Sie aktuelle Werte und Kontaktstatus für bis zu 50 Server eines Arbeitsbereichs. Nur Browsersitzungen. Unbekannte, entfernte oder verschobene Kennungen stehen in removed_ids, ohne andere Arbeitsbereiche offenzulegen.

• GET Empfangen Sie vollständige summaries-Ereignisse für die ausgewählten Server, auch zu Beginn und nach Wiederverbindung. Neu gespeicherte Werte erscheinen bei gesunder Verbindung innerhalb von fünf Sekunden. Ein Kontrollabgleich erfolgt alle vier Sekunden; Sitzung und Bereichszugriff werden vor jeder Ausgabe geprüft. access_revoked entfernt private Werte und beendet die Verbindung. Hintergrundtabs sollen die Verbindung schließen.

  Empfangen Sie vollständige summaries-Ereignisse für die ausgewählten Server, auch zu Beginn und nach Wiederverbindung. Neu gespeicherte Werte erscheinen bei gesunder Verbindung innerhalb von fünf Sekunden. Ein Kontrollabgleich erfolgt alle vier Sekunden; Sitzung und Bereichszugriff werden vor jeder Ausgabe geprüft. access_revoked entfernt private Werte und beendet die Verbindung. Hintergrundtabs sollen die Verbindung schließen.

• PATCH Auftragsdetails als gelesen markieren

  Markiert Hinweise zu eigenen Aufträgen als gelesen. Wiederholte Bestätigung bleibt ohne zusätzliche Wirkung; jeder Zugriff wird geprüft.

• POST Neue Auftragshinweise abrufen

  Gibt bis zu drei neue Abschlusshinweise einmalig über Ihre Browser-Tabs hinweg aus. Ungelesene Markierungen bleiben bis zum Öffnen der Details.

• POST Historien- oder Exportauftrag wiederholen

  Erstellt einen neuen Auftrag für denselben Zeitraum mit einem neuen Datenstand. Aktuelle Rechte, Datenfristen und Kontingente gelten. Dieselbe Vorgangskennung gibt denselben neuen Auftrag zurück.

• POST Eigene SLO- oder Berichtsanalyse wiederholen

  Erstellt eine neue Analyse für den ursprünglichen Zeitraum und unveränderte Quelleinstellungen. Geänderte oder entfernte Quellen erfordern eine neue Analyse aus der aktuellen Ansicht.

• GET Gespeicherte persönliche Navigation

  Lesen Sie kontoweit gespeicherte Favoriten und zuletzt geöffnete Ressourcen. Der aktuelle Zugriff wird für jede Ressource geprüft.

• GET Zugängliche Ressourcen suchen

  Durchsuchen Sie Monitore, Messreihen, Statusseiten, Gruppen, Alarmregeln, Vorfälle, Wartungspläne, Service-Level-Ziele, Berichtszeitpläne und Berichte nach Namen oder Kennung. Sie können nach Ressourcentyp filtern. Höchstens 20 zugängliche Treffer werden ausgegeben: genaue Kennungen zuerst, danach Namensanfänge.

• PUT Ressource als Favorit speichern

  Speichern Sie eine zugängliche Ressource als kontoweiten Favoriten. Wiederholungen sind ohne zusätzliche Wirkung; die Grenze von 50 Favoriten wird atomar geprüft.

• DELETE Persönlichen Favoriten entfernen

  Entfernen Sie eine Ressource aus Ihren Favoriten, ohne die Ressource zu ändern. Wiederholungen bleiben ohne Wirkung; ein vorhandener letzter Besuch bleibt erhalten.

• POST Geöffnete Ressource merken

  Merken Sie eine geöffnete Ressource nach Prüfung Ihres aktuellen Zugriffs. Ihr Konto hält höchstens 20 zuletzt geöffnete Ressourcen für 30 Tage vor.

• GET Live-Monitor- und Serverlisten

  Live-Monitor- oder Serverliste ausschließlich für Browsersitzungen. Verwendet dieselben Filter und dieselbe Seite wie getDevices, auch bei leerer Auswahl. devices-Ereignisse enthalten die vollständige Seite, Statuszähler und Facetten; access_revoked entfernt private Daten, invalidated erfordert ein erneutes Laden der Seite. Gemeinsame Streams aktualisieren bei bestehender Verbindung innerhalb von fünf Sekunden und pausieren in Hintergrundtabs.

• POST Verfügbarkeit und Antwortzeit

  Passen Sie Ihr persönliches Dashboard direkt an: Verschieben Sie Karten, wählen Sie Quellen, legen Sie Titel und Breiten fest und ergänzen Sie Monitor-, Kennzahl-, Diagramm- oder Wartungskarten. Änderungen gelten erst nach dem Speichern und beachten immer den Gruppenfilter.

• GET Einen Vorfall lesen

  Öffnen Sie einen zugänglichen Vorfall über seine Kennung, auch ältere und entwarnte Vorfälle innerhalb der verfügbaren Historie.

• POST HTTP-Antwortzeiten nach Standort und Region auswerten

  Vergleichen Sie alle aufbewahrten regulären HTTP-Prüfdauern nach Standort oder Weltregion in einem gemeinsamen Datenstand. Mittelwerte sind nach Messungsanzahl gewichtet; der Gesamtdurchschnitt berücksichtigt ausgeblendete Standorte. Fehlende Messungen bleiben Lücken. Die automatische Darstellung teilt ein Ergebnisbudget von 16.000 Anzeigepunkten und 4 MiB zwischen beiden Ansichten. Original- und Livegrenzen werden ausdrücklich angezeigt; Echtzeit-Alarmreihen bleiben unverändert.

• GET SSL-Zertifikatsdetails lesen

  Lesen Sie begrenzte, standortgebundene Zertifikatsnachweise. Automatische Zertifikatsdiagnosen und Resttagemessungen erfolgen stündlich, Domaindiagnosen täglich. Nachprüfungen erfordern Bearbeitungsrechte, ein gespeichertes Ziel, die aktuelle Konfigurationsrevision und eine Vorgangskennung. Sie nutzen Prüfkontingente, ohne reguläre HTTP-Messungen oder Alarmbestätigungen zu ändern. Unbekannte oder veraltete Nachweise bestätigen keine Gültigkeit.

• POST SSL-Zertifikat erneut prüfen

  Starten Sie eine revisionsgebundene reine TLS-Zertifikatsdiagnose an einem gespeicherten Monitorstandort. Erfordert Schreibrechte und freie Prüferkapazität; die HTTP-Anfrage wird nicht wiederholt und reguläre Telemetrie bleibt unverändert. Verwenden Sie bei Wiederholung dieselbe Vorgangs-ID.

• GET Status einer Zertifikatsneuprüfung lesen

  Lesen Sie Status und Abschlusszeit Ihrer Zertifikatsneuprüfung für diesen Monitor. Eine abgeschlossene Diagnose bestätigt keine Verfügbarkeit; aktuelle Zertifikatsnachweise liefert die TLS-Ansicht.

• GET Regeldiagnose lesen

  Begrenzte Auswertungsnachweise und Gründe einer aktiven oder archivierten Regel lesen, ohne einen Vorfall oder Zustellungen auszulösen. Maschinenzugriff benötigt telemetry:read und Zugriff auf den Arbeitsbereich der Regel.

• GET Browser-Journey-Übersicht lesen

  Liefert Browserlauf-Statistiken, Dauer und Web-Vitals für die ausgewählte Engine, den Standort und den aufbewahrten Zeitraum. Die Filteroptionen enthalten ausschließlich Engine-/Standortkombinationen mit gespeicherten Ergebnissen im selben Zeitraum, unabhängig von aktiven Filtern und Historienseiten.

• GET Browserlauf und Quellstand lesen

  Lesen Sie ein gespeichertes Browserergebnis und seinen ursprünglichen Konfigurationsstand ohne Geheimwerte. Ein fehlender historischer Quellstand bleibt null.

• GET Browseraufzeichnungen eines Entwurfs auflisten

  Listen Sie fertige Aufzeichnungen Ihres privaten Entwurfstests auf. Sie verfallen mit dem Entwurf, spätestens fünfzehn Minuten nach dessen Anlage.

• GET Browseraufzeichnung eines Entwurfs herunterladen

  Laden Sie eine fertige, berechtigte Entwurfsaufzeichnung vor ihrem Ablauf herunter. Videos enthalten maskierte Bilder und keinen Ton.

• POST Berichtsexport vorbereiten

  Erstellt einen Export des abgeschlossenen Datenstands oder verwendet einen bestehenden Export. CSV umfasst alle gefilterten Zeilen eines Abschnitts. PDF akzeptiert einen Abschnitt oder * für alle gewählten Abschnitte. PDF ist auf 60 Sekunden, 20 MiB und 100 Seiten begrenzt; zu große Ausgaben schlagen ohne Kürzung fehl.

• GET Exportfortschritt lesen

  Liefert den Exportstatus queued, running, completed oder failed. Laden Sie nur einen abgeschlossenen Export herunter.

• GET Berichtsexport herunterladen

  Lädt sämtliche CSV-Zeilen oder das vollständige PDF aus demselben festgehaltenen Datenstand. Konto-, Arbeitsbereichs- und konkrete Quellenrechte müssen weiterhin gültig sein.

• GET Berichtszeilen lesen

  Liest einen abgeschlossenen Abschnitt mit 50 Zeilen pro Seite. Filter und Summen sind im Bericht festgehalten. Verwenden Sie den zurückgegebenen Cursor für die nächste Seite. Downloads prüfen Arbeitsbereichs- und Ressourcenrechte erneut.

• GET Berichtsquellen auflisten

  Listet Berichtsabschnitte und erlaubte Monitore, Gruppen, Standorte und Dateisysteme auf. Viewer-Zugriff genügt; Maschinen benötigen telemetry:read.

• POST Bericht berechnen

  Erstellt einen begrenzten Analysejob oder verwendet einen identischen Job. Zeiträume sind bis 365 Tage, stündliche Gruppierungen bis 14 Tage möglich. Gruppenmitglieder werden beim Start festgehalten. Interaktive Ergebnisse laufen nach 24 Stunden ab. Rufen Sie den Analysejob bis zum Abschluss ab.

• GET Persönliche Berichtsauswahlen auflisten

  Persönliche Präferenzen für einen zugänglichen Arbeitsbereich, ausschließlich per Browsersitzung. Bis zu 50 benannte Auswahlen je Person und Arbeitsbereich, auch für Betrachter. Gespeichert werden Definition, Filter und Zeitraum, keine Ergebnisse oder Berechnungsaufträge. Änderungen benötigen CSRF. Nach verlorener Antwort dieselbe clientseitige ID und denselben Anlageinhalt wiederholen. Ändern und Löschen benötigen die aktuelle expected_revision; veraltete Änderungen liefern 409. Quellenrechte und Ergebnisfristen bleiben unverändert.

• POST Persönliche Berichtsauswahl speichern

  Persönliche Präferenzen für einen zugänglichen Arbeitsbereich, ausschließlich per Browsersitzung. Bis zu 50 benannte Auswahlen je Person und Arbeitsbereich, auch für Betrachter. Gespeichert werden Definition, Filter und Zeitraum, keine Ergebnisse oder Berechnungsaufträge. Änderungen benötigen CSRF. Nach verlorener Antwort dieselbe clientseitige ID und denselben Anlageinhalt wiederholen. Ändern und Löschen benötigen die aktuelle expected_revision; veraltete Änderungen liefern 409. Quellenrechte und Ergebnisfristen bleiben unverändert.

• PUT Persönliche Berichtsauswahl ändern

  Persönliche Präferenzen für einen zugänglichen Arbeitsbereich, ausschließlich per Browsersitzung. Bis zu 50 benannte Auswahlen je Person und Arbeitsbereich, auch für Betrachter. Gespeichert werden Definition, Filter und Zeitraum, keine Ergebnisse oder Berechnungsaufträge. Änderungen benötigen CSRF. Nach verlorener Antwort dieselbe clientseitige ID und denselben Anlageinhalt wiederholen. Ändern und Löschen benötigen die aktuelle expected_revision; veraltete Änderungen liefern 409. Quellenrechte und Ergebnisfristen bleiben unverändert.

• DELETE Persönliche Berichtsauswahl löschen

  Persönliche Präferenzen für einen zugänglichen Arbeitsbereich, ausschließlich per Browsersitzung. Bis zu 50 benannte Auswahlen je Person und Arbeitsbereich, auch für Betrachter. Gespeichert werden Definition, Filter und Zeitraum, keine Ergebnisse oder Berechnungsaufträge. Änderungen benötigen CSRF. Nach verlorener Antwort dieselbe clientseitige ID und denselben Anlageinhalt wiederholen. Ändern und Löschen benötigen die aktuelle expected_revision; veraltete Änderungen liefern 409. Quellenrechte und Ergebnisfristen bleiben unverändert.

• GET Limits für Liveansichten und Historien abrufen

  Liefert nur die wirksamen Kontolimits für Historien und Liveansichten. Mit workspace_id gelten die gemeinsamen Limits des berechtigten Arbeitsbereichsinhabers. Verbrauch und Prognosen werden nicht berechnet.

• GET Öffentlichen Bereitschaftsstatus lesen

  Prüft die Bereitschaft eines öffentlichen Dienstes, ohne private Diagnosen oder Monitoringdaten auszugeben.

• GET Verfügbarkeit und Fortschritt eines Agentupdates lesen

  Neue native Installationen aktivieren Fernupdates mit einem eigenen Schlüsselrecht. Sobald eine neuere freigegebene Version verfügbar ist, erscheint ein Symbol in der Serverliste. Der Arbeitsbereichsbesitzer bestätigt jedes Update; warten Sie anschließend auf die Bestätigung nach dem Neustart. Konfigurationsschreibrechte sind davon unabhängig. Vorübergehende Belegung liefert 503 mit update_busy und Retry-After: 1. Wiederholen Sie mit derselben operation_id und demselben bestätigten Ziel; die Oberfläche versucht dies bis zu zehn Sekunden. Bereits angenommene Anfragen liefern denselben Auftrag zurück. Die opake target_id bindet freigegebenes Release und Ausgangsinstallation/-version; bei Änderungen erneut laden und bestätigen.

• POST Agentupdate bestätigen

  Neue native Installationen aktivieren Fernupdates mit einem eigenen Schlüsselrecht. Sobald eine neuere freigegebene Version verfügbar ist, erscheint ein Symbol in der Serverliste. Der Arbeitsbereichsbesitzer bestätigt jedes Update; warten Sie anschließend auf die Bestätigung nach dem Neustart. Konfigurationsschreibrechte sind davon unabhängig. Vorübergehende Belegung liefert 503 mit update_busy und Retry-After: 1. Wiederholen Sie mit derselben operation_id und demselben bestätigten Ziel; die Oberfläche versucht dies bis zu zehn Sekunden. Bereits angenommene Anfragen liefern denselben Auftrag zurück. Die opake target_id bindet freigegebenes Release und Ausgangsinstallation/-version; bei Änderungen erneut laden und bestätigen.

• POST Update für die gebundene native Installation übernehmen

  Update für die gebundene native Installation übernehmen

• POST Fortschritt eines nativen Updates melden

  Fortschritt eines nativen Updates melden

• GET Freigegebene Logregeln lesen

  Ein Quellenschlüssel liest nur die eigene Aktivierung und Maskierung. Neue lokale Dateien oder Befehle kann er nicht freigeben.

• POST Abdeckung der Logerfassung melden

  Meldet den Erfassungs- oder Übertragungszustand einer ausgewählten Logteilquelle. Bereit allein bestätigt keine vollständige Übertragung; Cursorprüfpunkte werden gemeinsam mit ihren Logpaketen bestätigt. Gepufferte Unterbrechungen bleiben bis zum Nachweis der lückenlosen Fortsetzung offen.

• GET Logalarme auflisten

  Lesen Sie Logalarmdefinitionen, Zustellkonfiguration und aktuelle Auswertungsabdeckung des berechtigten Arbeitsbereichs.

• POST Logalarm erstellen

  Erstellen Sie einen Trefferanzahl- oder Ausbleibealarm mit eigenem Filter und Zustellzielen. Unvollständige Beobachtung bestätigt keine Entwarnung.

• DELETE Logalarm löschen

  Archivieren Sie eine Logregel und ihre Gruppeninstanzen und beenden Sie weitere Auswertungen und wartende Zustellungen.

• PUT Logalarm ändern

  Ändern Sie eine revisionsgebundene Logregel und ihre Gruppeninstanzen; vorhandene Vorfälle und Zusammenarbeit bleiben erhalten.

• POST Logexport erstellen

  Starten Sie einen CSV- oder NDJSON-Export mit festem Filterdatenstand. Eine Überschreitung der vollständigen Exportgrenze wird ausdrücklich abgelehnt statt abgeschnitten auszugeben.

• GET Logexportstatus lesen

  Lesen Sie den Status Ihres geschützten Exportauftrags. Der Download steht erst nach Fertigstellung des vollständigen Exports bereit.

• GET Logexport herunterladen

  Laden Sie einen vollständigen Export herunter, solange Arbeitsbereichsrechte, Quellenrevisionen und Aufbewahrung weiterhin gültig sind.

• POST Native Logs annehmen

  Nehmen Sie JSON, Arrays oder NDJSON mit optionalem gzip an. Maskieren Sie vor dauerhafter Bestätigung; stabile Kennungen verhindern doppelte Buchungen und Speicherung.

• POST Plattformlogs annehmen

  Prüfen Sie die konfigurierte Plattform und normalisieren Sie deren dokumentierte Nutzlast. Anbieterkennungen bleiben erhalten; ohne stabile Kennung wird nicht nach Nachrichtentext zusammengelegt.

• POST Logmaskierung voranzeigen

  Geben Sie ein maskiertes Beispiel zurück, ohne das Original zu speichern oder Logverbrauch zu buchen.

• POST Logsuche starten

  Starten Sie eine geschützte asynchrone Suche mit festem verfügbaren Datenstand. Zähler, Histogramm und Feldwerte umfassen alle Treffer unabhängig vom Seitencursor.

• DELETE Logsuche abbrechen

  Brechen Sie Ihren Suchauftrag ab oder entfernen Sie ihn. Ein laufender Worker kann ein gelöschtes Ergebnis nicht erneut veröffentlichen.

• GET Logsuchergebnis lesen

  Lesen Sie den aktorgebundenen Suchstatus oder sein fertiges Ergebnis nach erneuter Prüfung von Arbeitsbereichsrechten und Quellenaufbewahrung.

• GET Logquellen auflisten

  Lesen Sie Quellen und das eigene tägliche Logkontingent in einem berechtigten Arbeitsbereich.

• POST Logquelle erstellen

  Erstellen Sie eine Quelle ohne Monitor oder Messreihe. Die Erfassung bleibt ohne ausdrückliche Aktivierung ausgeschaltet.

• DELETE Logquelle löschen

  Sperren Sie den Zugriff, verwerfen Sie wartende Annahmen und entwerten Sie Suchergebnisse und Exporte. Die physische Löschung folgt innerhalb von 24 Stunden.

• PUT Logquelle ändern

  Ändern Sie eine Quelle mit ihrer Revision. Kürzere Aufbewahrung benötigt confirm_delete und entwertet betroffene Suchergebnisse sofort.

• POST Quellenclientzertifikat ersetzen

  Erstellen Sie ein quellengebundenes TLS-Clientzertifikat und geben Sie seinen privaten Schlüssel einmalig zurück. Frühere Quellenzertifikate werden widerrufen.

• DELETE Quellenzugangsdaten widerrufen

  Widerrufen Sie alle Quellenschlüssel und Clientzertifikate sofort, ohne gespeicherte Logeinträge zu löschen.

• POST Quellenschreibschlüssel ersetzen

  Erstellen Sie einen ausschließlich schreibenden Quellenschlüssel und widerrufen Sie bisherige Zugangsdaten. Der Klartext erscheint genau einmal.

• GET Live-Logs verfolgen

  Verfolgen Sie berechtigte indexierte Logs per SSE. Setzen Sie mit Last-Event-ID oder after fort; Lücken werden gemeldet und Rechte während des Streams erneut geprüft.

• GET Logverbrauch lesen

  Lesen Sie angenommene tägliche Logbytes und Einträge über alle Arbeitsbereiche des Ressourceninhabers einschließlich wirksamem Kontingent und nächstem UTC-Neustart.

• GET Gespeicherte Logansichten auflisten

  Lesen Sie Ihre persönlichen und die gemeinsamen Ansichten des gewählten Arbeitsbereichs.

• POST Logansicht speichern

  Speichern Sie eine persönliche Suchdefinition oder teilen Sie sie mit Bearbeitungsrechten. Alarmfilter bleiben von späteren Ansichtsänderungen unabhängig.

• DELETE Gespeicherte Logansicht löschen

  Löschen Sie Ihre gespeicherte Ansicht, ohne Logs zu löschen oder Alarmdefinitionen zu ändern.

• PUT Gespeicherte Logansicht ändern

  Ändern Sie Ihre eigene Ansicht mit ihrer erwarteten Revision; gemeinsame Ansichten benötigen zusätzlich Bearbeitungsrechte.

• POST OTLP-Logs annehmen

  Nehmen Sie OTLP/HTTP-Protobuf- oder Protobuf-JSON-Logs mit einem Quellenschlüssel an. Wiederholbare Fehler enthalten Retry-After und OTLP-Statusantworten.

• POST Dashboard-Kartenvorschauen lesen

  Lesen Sie aktuelle Daten für sichtbare Dashboard-Karten einschließlich ungespeicherter Vorschauen. Arbeitsbereich und Gruppe begrenzen immer die Quellen. Dieser Aufruf speichert kein Layout.

• GET Dashboard-Quellen suchen

  Suchen Sie berechtigte Quellen für eine Dashboard-Karte. Folgen Sie next_cursor für weitere Treffer. Die Auswahl verändert nur das Dashboard.

• POST Gespeicherten Monitor an öffentlichen Standorten testen

  Starten Sie eine idempotente Diagnose der gespeicherten Version an allen öffentlichen Standorten. Ungeeignete oder nicht verfügbare Standorte werden gesondert angezeigt. Ergebnisse verfallen nach 15 Minuten und erscheinen weder in der Prüfhistorie noch als Messwerte oder Alarme. Browser-, Mail- und schreibende HTTP-Prüfungen erfordern eine ausdrückliche Bestätigung.

• GET Vorübergehende Diagnoseergebnisse abrufen

  Lesen Sie einen gemeinsamen Stand mit Fortschritt und Ergebnissen je Standort. Nur der auslösende Benutzer kann die Diagnose bis höchstens 15 Minuten nach Beginn abrufen.

• POST Diagnose abbrechen

  Beenden Sie alle wartenden und laufenden Standortprüfungen. Wiederholter Abbruch ist sicher; verspätete Ergebnisse starten abgebrochene Arbeit nicht erneut.

• DELETE Die Heartbeat-URL deaktivieren

  Nur angemeldete Owner oder Editoren des Arbeitsbereichs dürfen diesen Zugang verwalten. Anzeigen benötigt CSRF-Schutz und liefert ein Geheimnis, das nicht im Browserspeicher abgelegt werden darf. Ersetzen und Deaktivieren benötigen expected_revision. Ersetzen entwertet die bisherige URL sofort; bei unklarer Antwort zunächst den aktuellen Stand lesen, nicht blind erneut ersetzen.

• GET Heartbeat-URL-Status lesen

  Nur angemeldete Owner oder Editoren des Arbeitsbereichs dürfen diesen Zugang verwalten. Anzeigen benötigt CSRF-Schutz und liefert ein Geheimnis, das nicht im Browserspeicher abgelegt werden darf. Ersetzen und Deaktivieren benötigen expected_revision. Ersetzen entwertet die bisherige URL sofort; bei unklarer Antwort zunächst den aktuellen Stand lesen, nicht blind erneut ersetzen.

• PUT Die Heartbeat-URL erzeugen oder ersetzen

  Nur angemeldete Owner oder Editoren des Arbeitsbereichs dürfen diesen Zugang verwalten. Anzeigen benötigt CSRF-Schutz und liefert ein Geheimnis, das nicht im Browserspeicher abgelegt werden darf. Ersetzen und Deaktivieren benötigen expected_revision. Ersetzen entwertet die bisherige URL sofort; bei unklarer Antwort zunächst den aktuellen Stand lesen, nicht blind erneut ersetzen.

• POST Die Heartbeat-URL anzeigen

  Nur angemeldete Owner oder Editoren des Arbeitsbereichs dürfen diesen Zugang verwalten. Anzeigen benötigt CSRF-Schutz und liefert ein Geheimnis, das nicht im Browserspeicher abgelegt werden darf. Ersetzen und Deaktivieren benötigen expected_revision. Ersetzen entwertet die bisherige URL sofort; bei unklarer Antwort zunächst den aktuellen Stand lesen, nicht blind erneut ersetzen.

• GET Joblauf über seine Heartbeat-URL messen

  GET, HEAD oder POST ohne Body. /start beginnt einen Lauf; die Basis-URL beendet ihn erfolgreich; /fail meldet Fehler; /abort Abbruch. Nur Erfolg bestätigt ein geplantes Lebenszeichen. Die optionale UUID run_id ordnet parallele Läufe zu und macht identische Phasen wiederholbar; widersprüchliche Abschlüsse liefern 409. Ohne Kennung darf nur eine Messung offen sein. Ein Basis-Heartbeat ohne offene Messung behält sein bisheriges Verhalten. Die Dauer verwendet Server-Empfangszeiten; ohne Start bleibt sie unbekannt. Jede neue Phase verbraucht ein normales Ereignis; Wiederholungen werden nicht doppelt gebucht. Geheimnisse niemals protokollieren und unklare Aufrufe ohne Laufkennung nicht automatisch wiederholen.

• HEAD Joblauf über seine Heartbeat-URL messen

  GET, HEAD oder POST ohne Body. /start beginnt einen Lauf; die Basis-URL beendet ihn erfolgreich; /fail meldet Fehler; /abort Abbruch. Nur Erfolg bestätigt ein geplantes Lebenszeichen. Die optionale UUID run_id ordnet parallele Läufe zu und macht identische Phasen wiederholbar; widersprüchliche Abschlüsse liefern 409. Ohne Kennung darf nur eine Messung offen sein. Ein Basis-Heartbeat ohne offene Messung behält sein bisheriges Verhalten. Die Dauer verwendet Server-Empfangszeiten; ohne Start bleibt sie unbekannt. Jede neue Phase verbraucht ein normales Ereignis; Wiederholungen werden nicht doppelt gebucht. Geheimnisse niemals protokollieren und unklare Aufrufe ohne Laufkennung nicht automatisch wiederholen.

• POST Joblauf über seine Heartbeat-URL messen

  GET, HEAD oder POST ohne Body. /start beginnt einen Lauf; die Basis-URL beendet ihn erfolgreich; /fail meldet Fehler; /abort Abbruch. Nur Erfolg bestätigt ein geplantes Lebenszeichen. Die optionale UUID run_id ordnet parallele Läufe zu und macht identische Phasen wiederholbar; widersprüchliche Abschlüsse liefern 409. Ohne Kennung darf nur eine Messung offen sein. Ein Basis-Heartbeat ohne offene Messung behält sein bisheriges Verhalten. Die Dauer verwendet Server-Empfangszeiten; ohne Start bleibt sie unbekannt. Jede neue Phase verbraucht ein normales Ereignis; Wiederholungen werden nicht doppelt gebucht. Geheimnisse niemals protokollieren und unklare Aufrufe ohne Laufkennung nicht automatisch wiederholen.

• GET Verfügbare Server

  Listet Server des Arbeitsbereichs mit begrenzten Logmetadaten, Fähigkeit und letztem Kontakt. Logtexte sind nicht enthalten.

• POST Logquelle verbinden

  Legt nach ausdrücklicher Auswahl eine Quelle und Teilquellen an oder passt sie an. Derselbe Vorgang mit gleichen Einstellungen erhält Ressourcen. Codes und Schlüssel erscheinen nur einmal.

• GET Verbindungsfortschritt

  Liefert Fortschritt und nicht geheime Einstellungen für den erstellenden Nutzer. Historischer Empfang bestätigt keine neue Einrichtung.

• POST Verlorenen Einrichtungscode ersetzen

  Ersetzt ausdrücklich einen verlorenen oder abgelaufenen Code für dieselbe aktuelle Auswahl. Funktionierende Quellenschlüssel bleiben erhalten.

• POST Anbieterweiterleitung einrichten

  Richtet ausschließlich das ausgewählte Anbieterziel mit der gebundenen Freigabe ein. Fremde Weiterleitungen werden nicht ersetzt.

• DELETE Teilquelle abschalten

  Lehnt weitere Einträge der Teilquelle sofort ab und erhält Historie und Leseposition. Neue Zugriffe benötigen lokale Zustimmung.

• GET Loganbindungswege

  Liefert unterstützte Verbindungswege und die Verfügbarkeit eingerichteter Anbieteranmeldungen.

• GET Anbieterfreigaben

  Listet aktive arbeitsbereichsgebundene Anbieterfreigaben dieses Nutzers ohne Zugangsdaten.

• POST Anbieter freigeben

  Prüft einen Anbieter-API-Token und speichert ihn verschlüsselt für Nutzer und Arbeitsbereich. Anbieterrechte und Gebühren gelten.

• GET Verfügbare Anbieterziele

  Liefert freigegebene Projekte, Anwendungen oder Zonen der Anbieteranbindung dieses Nutzers.

• DELETE Anbieterfreigabe widerrufen

  Entfernt gespeicherte Anbieterzugangsdaten. Bestehende Weiterleitung läuft bis zum Abschalten beim Anbieter oder an der Quelle weiter.

• POST Anbieteranmeldung starten

  Startet eine kurzlebige an Nutzer und Arbeitsbereich gebundene Anbieteranmeldung im Browser.

• GET Anbieteranmeldung abschließen

  Prüft Browsersitzung und einmaligen Zustand, speichert die Freigabe verschlüsselt und kehrt zur Logeinrichtung zurück.

• GET Lokaler Anbietereinrichtungsbefehl

  Lädt den festen Helfer für AWS, Fly.io und vorhandene Kubernetes-Collector. Lokale Anbieteranmeldung und ausdrückliche Zustimmung sind erforderlich.

• POST Lokale Anbietereinrichtung abrufen

  Tauscht einen kurzlebigen Einrichtungscode gegen festes Ziel und geschützte Konfiguration. Wiederholte Anwendung verwendet eigene Ressourcen weiter.

• POST Erkannte Logquellen melden

  Meldet bis zu 100 Kandidatenmetadaten mit der installierten Geräteidentität. Erkennung gewährt keine Leserechte.

• POST Agent-Logauswahl freigeben

  Zeigt die exakt codegebundene Auswahl mit der gebundenen Serveridentität und ruft sie ab. Erst nach lokaler Administratorzustimmung bestätigen; Erfolg oder Fehler melden.

• GET Verfügbare Logtypen

  Listet verfügbare Logtypen einer freigegebenen Cloudflare-Zone. Die Auswahl wird vor der Logpush-Anlage erneut geprüft.

• GET Unternehmensverbindungen auflisten

  Unternehmensverbindungen auflisten. Die Owner-Konfiguration benötigt eine frische aktionsgebundene Mailbestätigung. Testen Sie die Konfiguration vor der Aktivierung einer SSO-Pflicht. Persönliche und andere Firmenzugänge bleiben unabhängig.

• POST Unternehmensverbindung anlegen

  Unternehmensverbindung anlegen. Die Owner-Konfiguration benötigt eine frische aktionsgebundene Mailbestätigung. Testen Sie die Konfiguration vor der Aktivierung einer SSO-Pflicht. Persönliche und andere Firmenzugänge bleiben unabhängig.

• GET Unternehmensverbindung lesen

  Unternehmensverbindung lesen. Die Owner-Konfiguration benötigt eine frische aktionsgebundene Mailbestätigung. Testen Sie die Konfiguration vor der Aktivierung einer SSO-Pflicht. Persönliche und andere Firmenzugänge bleiben unabhängig.

• PUT SSO-Konfigurationsentwurf speichern

  SSO-Konfigurationsentwurf speichern. Die Owner-Konfiguration benötigt eine frische aktionsgebundene Mailbestätigung. Testen Sie die Konfiguration vor der Aktivierung einer SSO-Pflicht. Persönliche und andere Firmenzugänge bleiben unabhängig.

• DELETE Unternehmensverbindung löschen

  Unternehmensverbindung löschen. Die Owner-Konfiguration benötigt eine frische aktionsgebundene Mailbestätigung. Testen Sie die Konfiguration vor der Aktivierung einer SSO-Pflicht. Persönliche und andere Firmenzugänge bleiben unabhängig.

• PUT Arbeitsbereichsrichtlinie festlegen

  Arbeitsbereichsrichtlinie festlegen. Die Owner-Konfiguration benötigt eine frische aktionsgebundene Mailbestätigung. Testen Sie die Konfiguration vor der Aktivierung einer SSO-Pflicht. Persönliche und andere Firmenzugänge bleiben unabhängig.

• POST Unternehmensdomäne bestätigen

  Unternehmensdomäne bestätigen. Die Owner-Konfiguration benötigt eine frische aktionsgebundene Mailbestätigung. Testen Sie die Konfiguration vor der Aktivierung einer SSO-Pflicht. Persönliche und andere Firmenzugänge bleiben unabhängig.

• GET Firmenverzeichnis und Audit lesen

  Firmenverzeichnis und Audit lesen. Die Owner-Konfiguration benötigt eine frische aktionsgebundene Mailbestätigung. Testen Sie die Konfiguration vor der Aktivierung einer SSO-Pflicht. Persönliche und andere Firmenzugänge bleiben unabhängig.

• POST SCIM-Token rotieren

  SCIM-Token rotieren. Die Owner-Konfiguration benötigt eine frische aktionsgebundene Mailbestätigung. Testen Sie die Konfiguration vor der Aktivierung einer SSO-Pflicht. Persönliche und andere Firmenzugänge bleiben unabhängig.

• DELETE SCIM-Token widerrufen

  SCIM-Token widerrufen. Die Owner-Konfiguration benötigt eine frische aktionsgebundene Mailbestätigung. Testen Sie die Konfiguration vor der Aktivierung einer SSO-Pflicht. Persönliche und andere Firmenzugänge bleiben unabhängig.

• PUT Firmen-Gruppenrechte zuordnen

  Firmen-Gruppenrechte zuordnen. Die Owner-Konfiguration benötigt eine frische aktionsgebundene Mailbestätigung. Testen Sie die Konfiguration vor der Aktivierung einer SSO-Pflicht. Persönliche und andere Firmenzugänge bleiben unabhängig.

• POST Zugriffsantrag entscheiden

  Zugriffsantrag entscheiden. Die Owner-Konfiguration benötigt eine frische aktionsgebundene Mailbestätigung. Testen Sie die Konfiguration vor der Aktivierung einer SSO-Pflicht. Persönliche und andere Firmenzugänge bleiben unabhängig.

• POST Temporären Owner-Notzugang freigeben

  Temporären Owner-Notzugang freigeben. Die Owner-Konfiguration benötigt eine frische aktionsgebundene Mailbestätigung. Testen Sie die Konfiguration vor der Aktivierung einer SSO-Pflicht. Persönliche und andere Firmenzugänge bleiben unabhängig.

• POST Geprüfte SSO-Konfiguration aktivieren

  Geprüfte SSO-Konfiguration aktivieren. Die Owner-Konfiguration benötigt eine frische aktionsgebundene Mailbestätigung. Testen Sie die Konfiguration vor der Aktivierung einer SSO-Pflicht. Persönliche und andere Firmenzugänge bleiben unabhängig.

• GET Gespeicherten SSO-Entwurf lesen

  Gespeicherten SSO-Entwurf lesen. Die Owner-Konfiguration benötigt eine frische aktionsgebundene Mailbestätigung. Testen Sie die Konfiguration vor der Aktivierung einer SSO-Pflicht. Persönliche und andere Firmenzugänge bleiben unabhängig.

• POST Firmenmitgliedschaften übernehmen

  Firmenmitgliedschaften übernehmen. Die Owner-Konfiguration benötigt eine frische aktionsgebundene Mailbestätigung. Testen Sie die Konfiguration vor der Aktivierung einer SSO-Pflicht. Persönliche und andere Firmenzugänge bleiben unabhängig.

• POST Unternehmensanmeldung beginnen

  Unternehmensanmeldung beginnen. Die Unternehmensanmeldung ist browsergebunden. Bestehende Konten benötigen ausdrückliche Verknüpfung und frische Mailbestätigung; gleiche E-Mail-Adressen führen Identitäten nicht zusammen.

• GET OIDC-Anmeldeantwort empfangen

  OIDC-Anmeldeantwort empfangen. Die Unternehmensanmeldung ist browsergebunden. Bestehende Konten benötigen ausdrückliche Verknüpfung und frische Mailbestätigung; gleiche E-Mail-Adressen führen Identitäten nicht zusammen.

• POST SAML-Anmeldeantwort empfangen

  SAML-Anmeldeantwort empfangen. Die Unternehmensanmeldung ist browsergebunden. Bestehende Konten benötigen ausdrückliche Verknüpfung und frische Mailbestätigung; gleiche E-Mail-Adressen führen Identitäten nicht zusammen.

• GET Unternehmensanmeldung verwenden

  Unternehmensanmeldung verwenden. Die Unternehmensanmeldung ist browsergebunden. Bestehende Konten benötigen ausdrückliche Verknüpfung und frische Mailbestätigung; gleiche E-Mail-Adressen führen Identitäten nicht zusammen.

• GET Unternehmens-Anmeldevorgang lesen

  Unternehmens-Anmeldevorgang lesen. Die Unternehmensanmeldung ist browsergebunden. Bestehende Konten benötigen ausdrückliche Verknüpfung und frische Mailbestätigung; gleiche E-Mail-Adressen führen Identitäten nicht zusammen.

• POST Unternehmensanmeldung abschließen

  Unternehmensanmeldung abschließen. Die Unternehmensanmeldung ist browsergebunden. Bestehende Konten benötigen ausdrückliche Verknüpfung und frische Mailbestätigung; gleiche E-Mail-Adressen führen Identitäten nicht zusammen.

• GET Arbeitsbereichs-Anmeldelink lesen

  Arbeitsbereichs-Anmeldelink lesen. Die Unternehmensanmeldung ist browsergebunden. Bestehende Konten benötigen ausdrückliche Verknüpfung und frische Mailbestätigung; gleiche E-Mail-Adressen führen Identitäten nicht zusammen.

• GET SCIM-Benutzer auflisten

  SCIM-Benutzer auflisten. Verzeichnistokens gelten ausschließlich für ein Verzeichnis. Deaktivierung entzieht den Firmenzugriff, ohne das persönliche Konto zu löschen. Gruppenzuordnungen vergeben nur Viewer oder Editor.

• POST SCIM-Benutzer anlegen

  SCIM-Benutzer anlegen. Verzeichnistokens gelten ausschließlich für ein Verzeichnis. Deaktivierung entzieht den Firmenzugriff, ohne das persönliche Konto zu löschen. Gruppenzuordnungen vergeben nur Viewer oder Editor.

• GET SCIM-Benutzer lesen

  SCIM-Benutzer lesen. Verzeichnistokens gelten ausschließlich für ein Verzeichnis. Deaktivierung entzieht den Firmenzugriff, ohne das persönliche Konto zu löschen. Gruppenzuordnungen vergeben nur Viewer oder Editor.

• PUT SCIM-Benutzer ersetzen

  SCIM-Benutzer ersetzen. Verzeichnistokens gelten ausschließlich für ein Verzeichnis. Deaktivierung entzieht den Firmenzugriff, ohne das persönliche Konto zu löschen. Gruppenzuordnungen vergeben nur Viewer oder Editor.

• PATCH SCIM-Benutzer ändern

  SCIM-Benutzer ändern. Verzeichnistokens gelten ausschließlich für ein Verzeichnis. Deaktivierung entzieht den Firmenzugriff, ohne das persönliche Konto zu löschen. Gruppenzuordnungen vergeben nur Viewer oder Editor.

• DELETE SCIM-Benutzer löschen

  SCIM-Benutzer löschen. Verzeichnistokens gelten ausschließlich für ein Verzeichnis. Deaktivierung entzieht den Firmenzugriff, ohne das persönliche Konto zu löschen. Gruppenzuordnungen vergeben nur Viewer oder Editor.

• GET SCIM-Gruppen auflisten

  SCIM-Gruppen auflisten. Verzeichnistokens gelten ausschließlich für ein Verzeichnis. Deaktivierung entzieht den Firmenzugriff, ohne das persönliche Konto zu löschen. Gruppenzuordnungen vergeben nur Viewer oder Editor.

• POST SCIM-Gruppen anlegen

  SCIM-Gruppen anlegen. Verzeichnistokens gelten ausschließlich für ein Verzeichnis. Deaktivierung entzieht den Firmenzugriff, ohne das persönliche Konto zu löschen. Gruppenzuordnungen vergeben nur Viewer oder Editor.

• GET SCIM-Gruppe lesen

  SCIM-Gruppe lesen. Verzeichnistokens gelten ausschließlich für ein Verzeichnis. Deaktivierung entzieht den Firmenzugriff, ohne das persönliche Konto zu löschen. Gruppenzuordnungen vergeben nur Viewer oder Editor.

• PUT SCIM-Gruppe ersetzen

  SCIM-Gruppe ersetzen. Verzeichnistokens gelten ausschließlich für ein Verzeichnis. Deaktivierung entzieht den Firmenzugriff, ohne das persönliche Konto zu löschen. Gruppenzuordnungen vergeben nur Viewer oder Editor.

• PATCH SCIM-Gruppe ändern

  SCIM-Gruppe ändern. Verzeichnistokens gelten ausschließlich für ein Verzeichnis. Deaktivierung entzieht den Firmenzugriff, ohne das persönliche Konto zu löschen. Gruppenzuordnungen vergeben nur Viewer oder Editor.

• DELETE SCIM-Gruppe löschen

  SCIM-Gruppe löschen. Verzeichnistokens gelten ausschließlich für ein Verzeichnis. Deaktivierung entzieht den Firmenzugriff, ohne das persönliche Konto zu löschen. Gruppenzuordnungen vergeben nur Viewer oder Editor.

• GET SCIM-Dienstfähigkeiten lesen

  SCIM-Dienstfähigkeiten lesen. Verzeichnistokens gelten ausschließlich für ein Verzeichnis. Deaktivierung entzieht den Firmenzugriff, ohne das persönliche Konto zu löschen. Gruppenzuordnungen vergeben nur Viewer oder Editor.

• GET SCIM-Schemata lesen

  SCIM-Schemata lesen. Verzeichnistokens gelten ausschließlich für ein Verzeichnis. Deaktivierung entzieht den Firmenzugriff, ohne das persönliche Konto zu löschen. Gruppenzuordnungen vergeben nur Viewer oder Editor.

• GET ein SCIM-Schema lesen

  ein SCIM-Schema lesen. Verzeichnistokens gelten ausschließlich für ein Verzeichnis. Deaktivierung entzieht den Firmenzugriff, ohne das persönliche Konto zu löschen. Gruppenzuordnungen vergeben nur Viewer oder Editor.

• GET SCIM-Ressourcentypen lesen

  SCIM-Ressourcentypen lesen. Verzeichnistokens gelten ausschließlich für ein Verzeichnis. Deaktivierung entzieht den Firmenzugriff, ohne das persönliche Konto zu löschen. Gruppenzuordnungen vergeben nur Viewer oder Editor.

• GET einen SCIM-Ressourcentyp lesen

  einen SCIM-Ressourcentyp lesen. Verzeichnistokens gelten ausschließlich für ein Verzeichnis. Deaktivierung entzieht den Firmenzugriff, ohne das persönliche Konto zu löschen. Gruppenzuordnungen vergeben nur Viewer oder Editor.

• POST Native Alarmrückmeldungen empfangen

  Native Alarmrückmeldungen empfangen. Neue Ziele bleiben deaktiviert und benötigen eine ausdrückliche Alarmzuordnung. Rückkanäle prüfen die anbieterspezifische Authentifizierung; externer Abschluss entwarnt keine gemessene Störung. SMS und Anrufe benötigen Empfängerbestätigung und ein getrenntes Kostenbudget.

• POST Vorfall aus Slack bestätigen

  Vorfall aus Slack bestätigen. Neue Ziele bleiben deaktiviert und benötigen eine ausdrückliche Alarmzuordnung. Rückkanäle prüfen die anbieterspezifische Authentifizierung; externer Abschluss entwarnt keine gemessene Störung. SMS und Anrufe benötigen Empfängerbestätigung und ein getrenntes Kostenbudget.

• POST Slack-App-Autorisierung beginnen

  Slack-App-Autorisierung beginnen. Neue Ziele bleiben deaktiviert und benötigen eine ausdrückliche Alarmzuordnung. Rückkanäle prüfen die anbieterspezifische Authentifizierung; externer Abschluss entwarnt keine gemessene Störung. SMS und Anrufe benötigen Empfängerbestätigung und ein getrenntes Kostenbudget.

• GET Slack-App-Autorisierung abschließen

  Slack-App-Autorisierung abschließen. Neue Ziele bleiben deaktiviert und benötigen eine ausdrückliche Alarmzuordnung. Rückkanäle prüfen die anbieterspezifische Authentifizierung; externer Abschluss entwarnt keine gemessene Störung. SMS und Anrufe benötigen Empfängerbestätigung und ein getrenntes Kostenbudget.

• GET Autorisierte Slack-Workspaces auflisten

  Autorisierte Slack-Workspaces auflisten. Neue Ziele bleiben deaktiviert und benötigen eine ausdrückliche Alarmzuordnung. Rückkanäle prüfen die anbieterspezifische Authentifizierung; externer Abschluss entwarnt keine gemessene Störung. SMS und Anrufe benötigen Empfängerbestätigung und ein getrenntes Kostenbudget.

• GET Verfügbare Slack-Kanäle auflisten

  Verfügbare Slack-Kanäle auflisten. Neue Ziele bleiben deaktiviert und benötigen eine ausdrückliche Alarmzuordnung. Rückkanäle prüfen die anbieterspezifische Authentifizierung; externer Abschluss entwarnt keine gemessene Störung. SMS und Anrufe benötigen Empfängerbestätigung und ein getrenntes Kostenbudget.

• POST Persönliche Slack-Identität verknüpfen

  Persönliche Slack-Identität verknüpfen. Neue Ziele bleiben deaktiviert und benötigen eine ausdrückliche Alarmzuordnung. Rückkanäle prüfen die anbieterspezifische Authentifizierung; externer Abschluss entwarnt keine gemessene Störung. SMS und Anrufe benötigen Empfängerbestätigung und ein getrenntes Kostenbudget.

• POST Alarm-Empfängerrufnummer bestätigen

  Alarm-Empfängerrufnummer bestätigen. Neue Ziele bleiben deaktiviert und benötigen eine ausdrückliche Alarmzuordnung. Rückkanäle prüfen die anbieterspezifische Authentifizierung; externer Abschluss entwarnt keine gemessene Störung. SMS und Anrufe benötigen Empfängerbestätigung und ein getrenntes Kostenbudget.

• POST Temporären Owner-Notzugang freigeben

  Temporären Owner-Notzugang freigeben. Die Owner-Konfiguration benötigt eine frische aktionsgebundene Mailbestätigung. Testen Sie die Konfiguration vor der Aktivierung einer SSO-Pflicht. Persönliche und andere Firmenzugänge bleiben unabhängig.

• GET Optionalen Authenticator-Schutz verwalten

  Nur für bestätigte Browserkonten. Die Einrichtung erfordert eine frische aktionsgebundene Mailbestätigung; die Aktivierung zusätzlich einen gültigen Authenticator-Code und die Bestätigung von zehn Wiederherstellungscodes. Änderungen bestehender Faktoren erfordern eine frische starke Bestätigung. Andere Browsersitzungen werden widerrufen. Geheimnisse werden einmalig ausgegeben und dürfen nicht zwischengespeichert werden.

• DELETE Optionalen Authenticator-Schutz verwalten

  Nur für bestätigte Browserkonten. Die Einrichtung erfordert eine frische aktionsgebundene Mailbestätigung; die Aktivierung zusätzlich einen gültigen Authenticator-Code und die Bestätigung von zehn Wiederherstellungscodes. Änderungen bestehender Faktoren erfordern eine frische starke Bestätigung. Andere Browsersitzungen werden widerrufen. Geheimnisse werden einmalig ausgegeben und dürfen nicht zwischengespeichert werden.

• POST Optionalen Authenticator-Schutz verwalten

  Nur für bestätigte Browserkonten. Die Einrichtung erfordert eine frische aktionsgebundene Mailbestätigung; die Aktivierung zusätzlich einen gültigen Authenticator-Code und die Bestätigung von zehn Wiederherstellungscodes. Änderungen bestehender Faktoren erfordern eine frische starke Bestätigung. Andere Browsersitzungen werden widerrufen. Geheimnisse werden einmalig ausgegeben und dürfen nicht zwischengespeichert werden.

• POST Optionalen Authenticator-Schutz verwalten

  Nur für bestätigte Browserkonten. Die Einrichtung erfordert eine frische aktionsgebundene Mailbestätigung; die Aktivierung zusätzlich einen gültigen Authenticator-Code und die Bestätigung von zehn Wiederherstellungscodes. Änderungen bestehender Faktoren erfordern eine frische starke Bestätigung. Andere Browsersitzungen werden widerrufen. Geheimnisse werden einmalig ausgegeben und dürfen nicht zwischengespeichert werden.

• POST Optionalen Authenticator-Schutz verwalten

  Nur für bestätigte Browserkonten. Die Einrichtung erfordert eine frische aktionsgebundene Mailbestätigung; die Aktivierung zusätzlich einen gültigen Authenticator-Code und die Bestätigung von zehn Wiederherstellungscodes. Änderungen bestehender Faktoren erfordern eine frische starke Bestätigung. Andere Browsersitzungen werden widerrufen. Geheimnisse werden einmalig ausgegeben und dürfen nicht zwischengespeichert werden.

• GET Zweiten Faktor bestätigen

  Der erste Anmeldenachweis erzeugt nur eine browsergebundene Herausforderung für fünf Minuten. Übermitteln Sie einen Authenticator-Code oder einmaligen Wiederherstellungscode. Vor erfolgreicher Prüfung besteht keine nutzbare Sitzung. Höchstens fünf Fehlversuche je Vorgang; zusätzliche Konto- und Netzwerkgrenzen gelten. GET liest den aktuellen Vorgang; DELETE bricht ihn ab. Erneute Bestätigung erfordert zusätzlich die bestehende Sitzung und CSRF.

• POST Zweiten Faktor bestätigen

  Der erste Anmeldenachweis erzeugt nur eine browsergebundene Herausforderung für fünf Minuten. Übermitteln Sie einen Authenticator-Code oder einmaligen Wiederherstellungscode. Vor erfolgreicher Prüfung besteht keine nutzbare Sitzung. Höchstens fünf Fehlversuche je Vorgang; zusätzliche Konto- und Netzwerkgrenzen gelten. GET liest den aktuellen Vorgang; DELETE bricht ihn ab. Erneute Bestätigung erfordert zusätzlich die bestehende Sitzung und CSRF.

• DELETE Zweiten Faktor bestätigen

  Der erste Anmeldenachweis erzeugt nur eine browsergebundene Herausforderung für fünf Minuten. Übermitteln Sie einen Authenticator-Code oder einmaligen Wiederherstellungscode. Vor erfolgreicher Prüfung besteht keine nutzbare Sitzung. Höchstens fünf Fehlversuche je Vorgang; zusätzliche Konto- und Netzwerkgrenzen gelten. GET liest den aktuellen Vorgang; DELETE bricht ihn ab. Erneute Bestätigung erfordert zusätzlich die bestehende Sitzung und CSRF.

• POST Zweiten Faktor bestätigen

  Der erste Anmeldenachweis erzeugt nur eine browsergebundene Herausforderung für fünf Minuten. Übermitteln Sie einen Authenticator-Code oder einmaligen Wiederherstellungscode. Vor erfolgreicher Prüfung besteht keine nutzbare Sitzung. Höchstens fünf Fehlversuche je Vorgang; zusätzliche Konto- und Netzwerkgrenzen gelten. GET liest den aktuellen Vorgang; DELETE bricht ihn ab. Erneute Bestätigung erfordert zusätzlich die bestehende Sitzung und CSRF.

• GET Logkontext eines Vorfalls untersuchen

  Liefert gespeicherten Quellen- und Regelfilterkontext neuer Vorfälle oder klar gekennzeichnete aktuelle Zuordnungen älterer Vorfälle. Aktuelle Rechte und Aufbewahrung gelten immer. Optionale Felder incident_id, incident_scope (associated oder workspace) und incident_mode (matched, warnings oder all) verwenden den normalen Logworker und dessen Grenzen. Die Erweiterung auf den Arbeitsbereich ist ausdrücklich. Nachträgliche Suchergebnisse sind Untersuchungskontext, keine ursprünglichen Alarmnachweise.

• GET Vorfälle eines Logzeitfensters finden

  Liefert bis zu 100 überlappende Vorfälle für berechtigte Quellen eines Arbeitsbereichs. limited kennzeichnet die Begrenzung. source_ids ist ein JSON-Array mit höchstens 100 UUIDs. Zeitliche Überschneidung beweist keine Ursache.

• GET Joblauf über seine Heartbeat-URL messen

  GET, HEAD oder POST ohne Body. /start beginnt einen Lauf; die Basis-URL beendet ihn erfolgreich; /fail meldet Fehler; /abort Abbruch. Nur Erfolg bestätigt ein geplantes Lebenszeichen. Die optionale UUID run_id ordnet parallele Läufe zu und macht identische Phasen wiederholbar; widersprüchliche Abschlüsse liefern 409. Ohne Kennung darf nur eine Messung offen sein. Ein Basis-Heartbeat ohne offene Messung behält sein bisheriges Verhalten. Die Dauer verwendet Server-Empfangszeiten; ohne Start bleibt sie unbekannt. Jede neue Phase verbraucht ein normales Ereignis; Wiederholungen werden nicht doppelt gebucht. Geheimnisse niemals protokollieren und unklare Aufrufe ohne Laufkennung nicht automatisch wiederholen.

• HEAD Joblauf über seine Heartbeat-URL messen

  GET, HEAD oder POST ohne Body. /start beginnt einen Lauf; die Basis-URL beendet ihn erfolgreich; /fail meldet Fehler; /abort Abbruch. Nur Erfolg bestätigt ein geplantes Lebenszeichen. Die optionale UUID run_id ordnet parallele Läufe zu und macht identische Phasen wiederholbar; widersprüchliche Abschlüsse liefern 409. Ohne Kennung darf nur eine Messung offen sein. Ein Basis-Heartbeat ohne offene Messung behält sein bisheriges Verhalten. Die Dauer verwendet Server-Empfangszeiten; ohne Start bleibt sie unbekannt. Jede neue Phase verbraucht ein normales Ereignis; Wiederholungen werden nicht doppelt gebucht. Geheimnisse niemals protokollieren und unklare Aufrufe ohne Laufkennung nicht automatisch wiederholen.

• POST Joblauf über seine Heartbeat-URL messen

  GET, HEAD oder POST ohne Body. /start beginnt einen Lauf; die Basis-URL beendet ihn erfolgreich; /fail meldet Fehler; /abort Abbruch. Nur Erfolg bestätigt ein geplantes Lebenszeichen. Die optionale UUID run_id ordnet parallele Läufe zu und macht identische Phasen wiederholbar; widersprüchliche Abschlüsse liefern 409. Ohne Kennung darf nur eine Messung offen sein. Ein Basis-Heartbeat ohne offene Messung behält sein bisheriges Verhalten. Die Dauer verwendet Server-Empfangszeiten; ohne Start bleibt sie unbekannt. Jede neue Phase verbraucht ein normales Ereignis; Wiederholungen werden nicht doppelt gebucht. Geheimnisse niemals protokollieren und unklare Aufrufe ohne Laufkennung nicht automatisch wiederholen.

• GET Joblauf über seine Heartbeat-URL messen

  GET, HEAD oder POST ohne Body. /start beginnt einen Lauf; die Basis-URL beendet ihn erfolgreich; /fail meldet Fehler; /abort Abbruch. Nur Erfolg bestätigt ein geplantes Lebenszeichen. Die optionale UUID run_id ordnet parallele Läufe zu und macht identische Phasen wiederholbar; widersprüchliche Abschlüsse liefern 409. Ohne Kennung darf nur eine Messung offen sein. Ein Basis-Heartbeat ohne offene Messung behält sein bisheriges Verhalten. Die Dauer verwendet Server-Empfangszeiten; ohne Start bleibt sie unbekannt. Jede neue Phase verbraucht ein normales Ereignis; Wiederholungen werden nicht doppelt gebucht. Geheimnisse niemals protokollieren und unklare Aufrufe ohne Laufkennung nicht automatisch wiederholen.

• HEAD Joblauf über seine Heartbeat-URL messen

  GET, HEAD oder POST ohne Body. /start beginnt einen Lauf; die Basis-URL beendet ihn erfolgreich; /fail meldet Fehler; /abort Abbruch. Nur Erfolg bestätigt ein geplantes Lebenszeichen. Die optionale UUID run_id ordnet parallele Läufe zu und macht identische Phasen wiederholbar; widersprüchliche Abschlüsse liefern 409. Ohne Kennung darf nur eine Messung offen sein. Ein Basis-Heartbeat ohne offene Messung behält sein bisheriges Verhalten. Die Dauer verwendet Server-Empfangszeiten; ohne Start bleibt sie unbekannt. Jede neue Phase verbraucht ein normales Ereignis; Wiederholungen werden nicht doppelt gebucht. Geheimnisse niemals protokollieren und unklare Aufrufe ohne Laufkennung nicht automatisch wiederholen.

• POST Joblauf über seine Heartbeat-URL messen

  GET, HEAD oder POST ohne Body. /start beginnt einen Lauf; die Basis-URL beendet ihn erfolgreich; /fail meldet Fehler; /abort Abbruch. Nur Erfolg bestätigt ein geplantes Lebenszeichen. Die optionale UUID run_id ordnet parallele Läufe zu und macht identische Phasen wiederholbar; widersprüchliche Abschlüsse liefern 409. Ohne Kennung darf nur eine Messung offen sein. Ein Basis-Heartbeat ohne offene Messung behält sein bisheriges Verhalten. Die Dauer verwendet Server-Empfangszeiten; ohne Start bleibt sie unbekannt. Jede neue Phase verbraucht ein normales Ereignis; Wiederholungen werden nicht doppelt gebucht. Geheimnisse niemals protokollieren und unklare Aufrufe ohne Laufkennung nicht automatisch wiederholen.

• GET Joblauf über seine Heartbeat-URL messen

  GET, HEAD oder POST ohne Body. /start beginnt einen Lauf; die Basis-URL beendet ihn erfolgreich; /fail meldet Fehler; /abort Abbruch. Nur Erfolg bestätigt ein geplantes Lebenszeichen. Die optionale UUID run_id ordnet parallele Läufe zu und macht identische Phasen wiederholbar; widersprüchliche Abschlüsse liefern 409. Ohne Kennung darf nur eine Messung offen sein. Ein Basis-Heartbeat ohne offene Messung behält sein bisheriges Verhalten. Die Dauer verwendet Server-Empfangszeiten; ohne Start bleibt sie unbekannt. Jede neue Phase verbraucht ein normales Ereignis; Wiederholungen werden nicht doppelt gebucht. Geheimnisse niemals protokollieren und unklare Aufrufe ohne Laufkennung nicht automatisch wiederholen.

• HEAD Joblauf über seine Heartbeat-URL messen

  GET, HEAD oder POST ohne Body. /start beginnt einen Lauf; die Basis-URL beendet ihn erfolgreich; /fail meldet Fehler; /abort Abbruch. Nur Erfolg bestätigt ein geplantes Lebenszeichen. Die optionale UUID run_id ordnet parallele Läufe zu und macht identische Phasen wiederholbar; widersprüchliche Abschlüsse liefern 409. Ohne Kennung darf nur eine Messung offen sein. Ein Basis-Heartbeat ohne offene Messung behält sein bisheriges Verhalten. Die Dauer verwendet Server-Empfangszeiten; ohne Start bleibt sie unbekannt. Jede neue Phase verbraucht ein normales Ereignis; Wiederholungen werden nicht doppelt gebucht. Geheimnisse niemals protokollieren und unklare Aufrufe ohne Laufkennung nicht automatisch wiederholen.

• POST Joblauf über seine Heartbeat-URL messen

  GET, HEAD oder POST ohne Body. /start beginnt einen Lauf; die Basis-URL beendet ihn erfolgreich; /fail meldet Fehler; /abort Abbruch. Nur Erfolg bestätigt ein geplantes Lebenszeichen. Die optionale UUID run_id ordnet parallele Läufe zu und macht identische Phasen wiederholbar; widersprüchliche Abschlüsse liefern 409. Ohne Kennung darf nur eine Messung offen sein. Ein Basis-Heartbeat ohne offene Messung behält sein bisheriges Verhalten. Die Dauer verwendet Server-Empfangszeiten; ohne Start bleibt sie unbekannt. Jede neue Phase verbraucht ein normales Ereignis; Wiederholungen werden nicht doppelt gebucht. Geheimnisse niemals protokollieren und unklare Aufrufe ohne Laufkennung nicht automatisch wiederholen.

• GET Freigabe für zentralen Telefonversand anzeigen

  Erfordert eine verifizierte Browsersitzung und die aktuelle Rolle. Änderungen benötigen CSRF. Absenderidentität und Eigentümerwechsel verlangen zusätzlich eine frische aktionsgebundene Bestätigung. Anbieter-Geheimnisse werden nicht ausgegeben.

• GET Eigene Absenderdomains anzeigen

  Erfordert eine verifizierte Browsersitzung und die aktuelle Rolle. Änderungen benötigen CSRF. Absenderidentität und Eigentümerwechsel verlangen zusätzlich eine frische aktionsgebundene Bestätigung. Anbieter-Geheimnisse werden nicht ausgegeben.

• POST Absenderdomain hinzufügen

  Erfordert eine verifizierte Browsersitzung und die aktuelle Rolle. Änderungen benötigen CSRF. Absenderidentität und Eigentümerwechsel verlangen zusätzlich eine frische aktionsgebundene Bestätigung. Anbieter-Geheimnisse werden nicht ausgegeben.

• POST Absenderdomain widerrufen

  Erfordert eine verifizierte Browsersitzung und die aktuelle Rolle. Änderungen benötigen CSRF. Absenderidentität und Eigentümerwechsel verlangen zusätzlich eine frische aktionsgebundene Bestätigung. Anbieter-Geheimnisse werden nicht ausgegeben.

• POST Signierschlüssel des Absenders wechseln

  Erfordert eine verifizierte Browsersitzung und die aktuelle Rolle. Änderungen benötigen CSRF. Absenderidentität und Eigentümerwechsel verlangen zusätzlich eine frische aktionsgebundene Bestätigung. Anbieter-Geheimnisse werden nicht ausgegeben.

• POST Absender-DNS erneut prüfen

  Erfordert eine verifizierte Browsersitzung und die aktuelle Rolle. Änderungen benötigen CSRF. Absenderidentität und Eigentümerwechsel verlangen zusätzlich eine frische aktionsgebundene Bestätigung. Anbieter-Geheimnisse werden nicht ausgegeben.

• GET Zustellstatus des Absenders anzeigen

  Erfordert eine verifizierte Browsersitzung und die aktuelle Rolle. Änderungen benötigen CSRF. Absenderidentität und Eigentümerwechsel verlangen zusätzlich eine frische aktionsgebundene Bestätigung. Anbieter-Geheimnisse werden nicht ausgegeben.

• PUT Statusseiten-Absenderentwurf speichern

  Erfordert eine verifizierte Browsersitzung und die aktuelle Rolle. Änderungen benötigen CSRF. Absenderidentität und Eigentümerwechsel verlangen zusätzlich eine frische aktionsgebundene Bestätigung. Anbieter-Geheimnisse werden nicht ausgegeben.

• POST Besuchermail mit eigenem Branding ansehen

  Erfordert eine verifizierte Browsersitzung und die aktuelle Rolle. Änderungen benötigen CSRF. Absenderidentität und Eigentümerwechsel verlangen zusätzlich eine frische aktionsgebundene Bestätigung. Anbieter-Geheimnisse werden nicht ausgegeben.

• POST Statusseiten-Absender prüfen

  Erfordert eine verifizierte Browsersitzung und die aktuelle Rolle. Änderungen benötigen CSRF. Absenderidentität und Eigentümerwechsel verlangen zusätzlich eine frische aktionsgebundene Bestätigung. Anbieter-Geheimnisse werden nicht ausgegeben.

• POST Marken-Testmail an die eigene verifizierte Adresse senden

  Erfordert eine verifizierte Browsersitzung und die aktuelle Rolle. Änderungen benötigen CSRF. Absenderidentität und Eigentümerwechsel verlangen zusätzlich eine frische aktionsgebundene Bestätigung. Anbieter-Geheimnisse werden nicht ausgegeben.

• GET Status der Eigentumsübergabe anzeigen

  Erfordert eine verifizierte Browsersitzung und die aktuelle Rolle. Änderungen benötigen CSRF. Absenderidentität und Eigentümerwechsel verlangen zusätzlich eine frische aktionsgebundene Bestätigung. Anbieter-Geheimnisse werden nicht ausgegeben.

• POST Eigentumsübergabe vorschlagen

  Erfordert eine verifizierte Browsersitzung und die aktuelle Rolle. Änderungen benötigen CSRF. Absenderidentität und Eigentümerwechsel verlangen zusätzlich eine frische aktionsgebundene Bestätigung. Anbieter-Geheimnisse werden nicht ausgegeben.

• POST Eigentumsübergabe vorschauen

  Erfordert eine verifizierte Browsersitzung und die aktuelle Rolle. Änderungen benötigen CSRF. Absenderidentität und Eigentümerwechsel verlangen zusätzlich eine frische aktionsgebundene Bestätigung. Anbieter-Geheimnisse werden nicht ausgegeben.

• POST Eigentum am Arbeitsbereich annehmen

  Erfordert eine verifizierte Browsersitzung und die aktuelle Rolle. Änderungen benötigen CSRF. Absenderidentität und Eigentümerwechsel verlangen zusätzlich eine frische aktionsgebundene Bestätigung. Anbieter-Geheimnisse werden nicht ausgegeben.

• POST Eigentumsübergabe widerrufen

  Erfordert eine verifizierte Browsersitzung und die aktuelle Rolle. Änderungen benötigen CSRF. Absenderidentität und Eigentümerwechsel verlangen zusätzlich eine frische aktionsgebundene Bestätigung. Anbieter-Geheimnisse werden nicht ausgegeben.

• GET Sichere Alarmeinstellungen, Empfänger und Regelvorschläge eines Monitors lesen. Kanalzugangsdaten werden niemals ausgegeben.

  Sichere Alarmeinstellungen, Empfänger und Regelvorschläge eines Monitors lesen. Kanalzugangsdaten werden niemals ausgegeben.

• PUT Die gemeinsame Empfängervorgabe mit erwarteter Revision speichern. Individuelle Ausnahmen und bestehende Vorfallsnapshots bleiben erhalten. Ausdrückliche Übernahme ist auf 100 Regelkennungen begrenzt.

  Die gemeinsame Empfängervorgabe mit erwarteter Revision speichern. Individuelle Ausnahmen und bestehende Vorfallsnapshots bleiben erhalten. Ausdrückliche Übernahme ist auf 100 Regelkennungen begrenzt.