Checkmk
to checkmk.com

1. Einleitung

Mit der Checkmk REST-API als Anwendungsprogrammierschnittstelle können Sie die Aufgaben, die Sie sonst in Checkmk über die GUI erledigen, per Kommando oder Skript mit HTTP-Anfragen an den Checkmk-Server übermitteln und ausführen lassen.

Das REST im Begriff REST-API steht für REpresentational State Transfer und beschreibt eine Architektur für den Austausch von Daten auf verteilten Systemen — insbesondere für Web-Dienste. Eine API, die gemäß der REST-Architektur implementiert ist, folgt bestimmten Prinzipien, z.B. dem Client-Server-Modell, der zustandslosen Kommunikation und einer einheitlichen Schnittstelle. In der Praxis erfolgt die Umsetzung bevorzugt über das HTTP-Protokoll, wobei die Ressourcen per Uniform Resource Identifier (URI) angesprochen werden und auf diese mit HTTP-Methoden (GET, POST, PUT, DELETE) zugegriffen wird.

Soviel zu den REST-Prinzipien. Ihre Vorteile zeigen sich in den konkreten Features, die Ihnen die Checkmk REST-API bietet:

Protokoll

Das Hypertext Transfer Protocol (HTTP/1.1) wird als Transportsystem für die Kommunikation genutzt.

Kodierung

Als Datenformat wird die JavaScript Object Notation (JSON) verwendet. Die Nutzdaten (payload) der Antworten werden mit JSON serialisiert und in UTF-8 kodiert. Datums- und Zeitangaben sind im ISO-8601-Format mit gültigen Zeitzoneninformationen kodiert.

Sprache

Englisch ist die Sprache für Labels, Identifiers und die API-Dokumentation.

Authentifizierung

Der Zugriff auf die API wird einem Client nur dann gestattet, wenn er die Berechtigung mittels HTTP-Authentifizierung (z.B. „Bearer“) nachgewiesen hat.

Versionierung

Die API ist versioniert und folgt den Grundprinzipien des Standards Semantic Versioning 2.x. Details finden Sie im Abschnitt zur Versionierung weiter unten.

Dokumentation

Die API wird in einem maschinenlesbaren Schema und einem menschenlesbaren Format in englischer Sprache dokumentiert, mit allen Ressourcen, ihren Eingabe- und Ausgabeparametern und den zugehörigen Wertebereichen. Die API ist mit der OpenAPI Specification (OAS) 3.x erstellt, einem API-Beschreibungsformat speziell für REST-APIs. Das mit dieser Spezifikation erstellte API-Dokument wird für den Benutzer mit ReDoc angezeigt, einem responsiven Web-Design für OpenAPI-Dokumente.

Beispiel-Code

Um die Verwendung zu demonstrieren, gibt es in der Dokumentation der REST-API zu jeder Anfrage Beispiel-Code für verschiedene Anwendungen (z.B. für Python mit Requests oder Bash mit Curl).

Fehleranzeige

Die API sendet im Fehlerfall numerische HTTP-Status-Codes und eine Diagnosemeldung des Problems, die bei der Suche nach möglichen Ursachen für fehlerhafte Anfragen hilft.

REST-API Klassifizierung

Die API erfüllt alle vier Ebenen (0 bis 3) des Richardson Maturity Model (RMM), mit dem beurteilt werden kann, wie viel REST in einer API steckt. In Ebene 1 wird die Einführung von Ressourcen gefordert, damit über die API statt zu einem globalen Endpunkt zu individuellen Endpunkten kommuniziert werden kann. Ebene 2 wird erfüllt, wenn für die Anfragen HTTP-Methoden verwendet werden. Auf der (höchsten) Ebene 3 dokumentiert sich die API quasi selbst, indem der Server mit der Antwort auf eine Anfrage die nächsten möglichen Aktionen und die dabei anzusprechenden Ressourcen mitteilt, und es dem Client so ermöglicht, die verfügbare Funktionalität selbst zu entdecken. Diese Bereitstellung von Zusatzinformationen wird auch „Hypermedia as the Engine of Application State“ (HATEOAS) genannt.

Neben diesen generellen Komfortfunktionen soll die REST-API die komplette Funktionalität abdecken, die Checkmk über die GUI und über Kommandoschnittstelle bietet.

CEE Für Funktionen, die es nur in den kommerziellen Editionen gibt, wie z.B. Service Level Agreement (SLA) oder Agentenbäckerei, werden die zugehörigen Methoden der REST-API auch nur in diesen Editionen angeboten. In der Dokumentation für die REST-API finden Sie für jede Funktion Hinweise dazu, in welchen Editionen sie verfügbar ist.

2. Versionierung

Einer der Vorteile der REST-API ist, dass Software und Dokumentation aus der gleichen Quelle stammen: dem OpenAPI-Dokument. Daher passt die API-Dokumentation stets zur Software und beschreibt genau das, was die API kann. Daher ist es auch nicht nötig, den Referenzteil der verfügbaren Ressourcen, Methoden, Parameter etc. im Checkmk-Handbuch zu beschreiben: stattdessen finden Sie die API-Dokumentation außerhalb dieses Handbuchs, direkt in Ihrer Checkmk-Instanz.

Die API mit ihrer Dokumentation ist versioniert. Seit Checkmk 2.5.0 wird die REST-API in der Version v1 mit der Checkmk-Software zusammen ausgeliefert. Diese Version der API ist kompatibel mit der Version 1.0, die bis Checkmk 2.4.0 zur Verfügung gestellt wird. Die Versionsnummer ist Bestandteil der URL, mit der eine API-Anfrage an den Server gesendet wird.

Das Schema für die Versionierung ab v1 basiert auf den Grundprinzipien der Spezifikation für Semantic Versioning 2.x. Die Versionsbezeichnungen der REST-API von Checkmk drücken allerdings ausschließlich die Ebene der Major-Version aus. Bei inkompatiblen Änderungen erhöht sich die Major-Versionsnummer der REST-API. Bug Fixes (Patch-Versionen) und kompatible Änderungen (Minor-Versionen) finden ab der Version v1 nur „unter der Haube“ statt und erfordern keine Änderung des Pfads für API-Anfragen.

Die Versionierung der REST-API für Checkmk ist unabhängig von der Versionierung der Checkmk-Software selbst. Änderungen von API-Funktionen — in Form von Bug Fixes, kompatiblen Änderungen oder sogar als neue Major-Version mit inkompatiblen Änderungen — können in jeder Patch-Version von Checkmk ausgeliefert werden. Hierüber werden Sie wie gewohnt über Werks informiert.

Erscheint eine neue Major-Version der REST-API, können Sie vorübergehend weiterhin die vorige Version der REST-API nutzen. Abkündigungen veralteter Versionen der REST-API werden mit genügend Vorlauf bekanntgegeben. Erst mit der nächsten Major-Version von Checkmk werden abgekündigte API-Versionen entfernt. So liegt es in Ihrer Hand, wann Sie Ihre Skripte auf die neue REST-API-Version aktualisieren. Im Artikel zum Update auf Version 2.5.0 finden Sie aktuelle Informationen über den empfohlenen Umgang mit den in dieser Checkmk-Major-Version unterstützten REST-API-Versionen.

Tip

Zusätzlich zu den unterstützten Major-Versionen der REST-API haben Sie auch die Möglichkeit, die Version unstable mit Ihren API-Anfragen anzusteuern. Diese Version bietet Ihnen beispielsweise Zugriff auf Funktionen, die sich aktuell noch in der Entwicklung befinden. Wie der Name schon andeutet, wird die unstable-Version nicht unterstützt und bietet keine Garantie auf Kompatibilität. Mehr über die unstable-Version der REST-API erfahren Sie im entsprechenden Abschnitt dieses Artikels.

3. Die API-Dokumentation

3.1. Zugriff

Die REST-API-Dokumentation steht im HTML-Format zur Ansicht im Web-Browser bereit.

In der Checkmk-GUI öffnen Sie die API-Dokumentation über die Navigationsleiste mit Help > Developer resources > REST API > Version 1 > Documentation. In diesem Menü stehen zu jedem Zeitpunkt alle REST-API-Versionen zur Auswahl, die von der Checkmk-Version Ihrer Instanz unterstützt werden.

Help-Menü in der Navigationsleiste.
Im Help-Menü zur REST-API finden Sie Ressourcen zu allen von Ihrer Instanz unterstützten Versionen der REST-API

Mit dem Menüpunkt Introduction können Sie diesen Artikel öffnen. Neben dem Eintrag Documentation gibt es für jede Major-Version der REST-API außerdem die Möglichkeit, mit Interactive GUI die interaktive GUI der REST-API zu öffnen. Hinweise zur Nutzung der unstable-Version der REST-API finden Sie in einem eigenen Abschnitt dieses Artikels.

Wenn Sie im Help-Menü den Eintrag Documentation für die gewünschte API-Version auswählen, wird die API-Dokumentation in einem neuen Browser-Fenster (bzw. Browser-Tab) angezeigt. Sie wurde beim Anlegen Ihrer Instanz mitgeliefert, wurde aber separat mit ReDoc generiert und sieht daher anders aus als die Seiten der Checkmk-Web-GUI.

3.2. Struktur und Inhalt

Die API-Dokumentation nutzt ein responsives Web-Design mit 3 Bereichen:

API-Dokumentation im responsiven Web-Design mit drei Bereichen.
Die Dokumentation gibt Ihnen einen Überblick über alle verfügbaren Endpunkte und deren Verwendung
  • Der linke Navigationsbereich dient der Orientierung, der Suche und dem schnellen Sprung zur genauen Beschreibung der Einträge im mittleren Bereich. Das Inhaltsverzeichnis enthält für jeden API-Endpunkt einen Eintrag. Ein Endpunkt bezeichnet per URL die Ressource, die die API zur Verfügung stellt (z.B. Hosts), zusammen mit der Methode, um auf die Ressource zuzugreifen (z.B. GET zur Anzeige eines Hosts). Die Endpunkte sind in mehrere Ordner organisiert.

  • Der mittlere Inhaltsbereich enthält die harten Fakten der Dokumentation: alle Informationen zur Definition einer Anfrage (mit Parametern, Wertebereichen, Default-Werten und Beschreibungen) und die zugehörigen Antworten (ebenfalls mit allen Details). Die möglichen Antworten werden in unterschiedlichen Farben dargestellt, je nachdem ob der zurückgelieferte HTTP-Status-Code Erfolg oder einen Fehler signalisiert.

  • Der rechte Beispielbereich (Request samples) zeigt für den im Inhaltsbereich ausgewählten Endpunkt die Methode und die URL, gefolgt von mehreren Beispielen zu Anfragen: die Payload im JSON-Format (falls relevant für den Endpunkt) und Code-Beispiele z.B. für Python mit requests, Python mit urllib, Bash mit Httpie und Bash mit Curl. Darunter folgen die Antworten passend zum HTTP-Status-Code. Alle Code-Beispiele können über den Knopf Copy in die Zwischenablage kopiert werden.

Der Navigationsbereich ist scroll-synchronisiert zu den anderen beiden Bereichen, das heißt, wenn Sie im Inhaltsbereich nach oben oder unten scrollen, scrollt der Navigationsbereich automatisch zum passenden Eintrag des Inhaltsverzeichnisses mit.

Das responsive Web-Design sorgt dafür, dass in einem Browser-Fenster mit geringer Breite der Beispielbereich verschwindet (dafür werden dann die Beispiele unterhalb der zugehörigen Methode angezeigt) und der Navigationsbereich in ein Menü umgewandelt wird.

In allen Bereichen finden Sie Inhalte, die Sie ein- und ausblenden können, zum Beispiel im Navigationsbereich die Einträge für die Endpunkte und im Inhaltsbereich verschachtelte Parameter. Durch Anklicken von > oder Expand all blenden Sie die verborgenen Inhalte ein und mit ∨ oder Collapse all wieder aus.

Wie Sie die API-Dokumentation nutzen können, um konkrete Anfragen zu erstellen, an den Checkmk-Server zu senden, ausführen zu lassen und den Erfolg zu kontrollieren: all das erfahren Sie im nächsten Kapitel.

4. Die API nutzen

4.1. Authentifizierung

Um von einem Client aus die REST-API des Checkmk-Servers nutzen zu können, muss der Client seine Identität nachweisen. Die REST-API unterstützt die folgenden Methoden zur Authentifizierung: Bearer, Webserver und Cookie — in dieser Rangfolge. Das heißt zum Beispiel, dass bei einer erfolgreichen Authentifizierung mit Bearer keine der anderen Methoden mehr geprüft wird.

Bearer- oder Header-Authentifizierung

„Bearer“ bezeichnet den Träger oder Inhaber einer Identität. Der Client authentisiert sich mit den Zugangsdaten eines auf dem Checkmk-Server eingerichteten Benutzers. Idealerweise ist dies ein sogenannter Automationsbenutzer, der in Checkmk für die Ausführung von Aktionen über eine API vorgesehen ist. Die Bearer-Authentifizierung wird für die Verwendung in Skripten empfohlen.

Für die Authentifizierung benötigen Sie den Benutzernamen und das zugehörige, sogenannte automation secret for machine accounts, das heißt das Passwort des Automationsbenutzers. Beide Informationen müssen im Header jeder Anfrage an den Checkmk-Server übermittelt werden.

Sie finden Automationsbenutzer, wie andere Benutzer auch, unter Setup > Users > Users. Um alle Endpunkte der REST-API zu nutzen, brauchen Sie einen Automationsbenutzer mit recht umfangreichen Berechtigungen.

Tipps: Geeigneten Automationsbenutzer anlegen

Legen Sie zunächst die Berechtigungen für Ihren Automationsbenutzer unter Setup > Users > Roles and permissions fest. Dort existiert standardmäßig bereits eine Rolle admin mit sämtlichen Berechtigungen sowie eine Rolle no_permissions mit überhaupt keinen Berechtigungen. Kopieren Sie je nach gewünschtem Umfang der Berechtigungen für den neuen Automationsbenutzer eine dieser Rollen und geben Sie der Kopie einen sprechenden Namen. Nun können Sie für die neu angelegte Rolle Berechtigungen einzeln aktivieren oder deaktivieren.

Erstellen Sie als nächstes unter Setup > Users > Users einen neuen Benutzer mit sprechendem Namen, beispielsweise automation. Die Eigenschaften für den neu angelegten Automationsbenutzer konfigurieren Sie so wie im Artikel über Benutzer und Berechtigungen beschrieben. Wählen Sie als Rolle die von Ihnen zuvor neu erstellte Rolle, um dem neuen Benutzer so alle benötigten Berechtigungen zuzuweisen.

Für die in diesem Artikel vorgestellten Skripte wird immer ein Automationsbenutzer namens automation als Beispiel genommen.

Webserver-Authentifizierung

Bei der Webserver-Authentifizierung nutzt die REST-API die HTTP-Authentifizierung, die für den Webserver konfiguriert ist („Basic“ oder „Digest“).

Diese Authentifizierungsmethode ist gedacht für große Checkmk-Installationen mit speziellen Anforderungen, die durch den Einsatz und die Konfiguration von Software-Modulen für die Authentifizierung des Apache Webservers realisiert werden. Wenn Sie die Webserver-Authentifizierung nutzen möchten, müssen Sie den Apache Webserver der Checkmk-Instanz selbst neu konfigurieren.

Cookie-Authentifizierung

Die Cookie-Authentifizierung ist ein Spezialfall der Authentifizierung per API-Schlüssel. Jeder Checkmk-Benutzer, der in Checkmk angemeldet ist und dadurch ein HTTP Cookie zugewiesen bekommen hat, kann die REST-API nutzen. Die Cookie-Authentifizierung dient zum Ausprobieren und Testen mit der interaktiven GUI der REST-API. Ob Anfragen ausgeführt werden können, hängt davon ab, ob Ihr Checkmk-Benutzerkonto die entsprechenden Berechtigungen besitzt.

4.2. HTTP-Status-Code

Die REST-API gibt zu jeder Anfrage den HTTP-Status-Code zurück, mit dem Sie überprüfen können, ob die Anfrage erfolgreich war. Alle für die Anfrage möglichen HTTP-Status-Codes werden in der API-Dokumentation gelistet.

Beachten Sie, dass der HTTP-Status-Code nur Auskunft über die erfolgreiche Übermittlung der Anfrage gibt, aber nicht über die erfolgreiche Ausführung. Ausgeführt werden die Befehle auf dem Checkmk-Server mit Livestatus. Um sicher zu sein, dass die Anfrage über die REST-API auch wirklich das bewirkt, was Sie beabsichtigt haben, müssen Sie die Erfolgskontrolle selbst übernehmen. Die API-Dokumentation enthält im Abschnitt „Queries through the REST API“ ein Beispiel eines Skripts für diese Aufgabe.

4.3. Vorbereitungen

Um die REST-API zu nutzen, benötigt das Endgerät, von dem Sie die Anfragen verschicken möchten, eine Verbindung zum Checkmk-Server. Sie können für erste Tests beispielsweise direkt auf dem Checkmk-Server arbeiten. Wenn Sie als Instanzbenutzer arbeiten, können Sie lokale Variablen wie z.B. $OMD_SITE verwenden, die auf den Namen der Instanz verweist.

Die Beispiele in den folgenden Abschnitten sind allgemein gehalten und verwenden diese lokalen Variablen nicht. Sie sind also auf jedem Gerät ausführbar, das eine Verbindung zum Checkmk-Server herstellen kann.

Im Folgenden zeigen wir für einige einfache Beispiele Python-Skripte, in denen die HTTP-Anfragen an die API mit dem Modul requests umgesetzt sind. Daneben finden Sie für jedes Beispiel auch eine Curl-Variante. Inhaltlich sind die alternativen Implementierungen deckungsgleich. Zu möglichen Unterschieden im Verhalten der verwendeten Werkzeuge, zum Beispiel in Bezug auf Redirects, empfehlen wir einen Blick in die Dokumentation des jeweiligen Tools.

Wenn Sie mit Python auf die REST-API zugreifen möchten, benötigen Sie eine funktionierende Umgebung mit Python 3 und dem requests-Modul.

Curl ist unter Linux, Windows und macOS vorinstalliert, allerdings ist die hier gezeigte Kapselung in Shell-Skripten mit Variablen nur unter Linux und macOS Out-of-the-Box möglich. Unter Windows können Sie mit dem Windows Subsystem for Linux eine vergleichbare Umgebung installieren.

Zur Vorbereitung erstellen Sie für jede der im nächsten Abschnitt auszuführenden Anfragen jeweils eine Skript-Datei, in die später der Beispiel-Code kopiert wird:

Python mit requests
Bash mit curl
Python mit requests

Für die requests-Beispiele legen Sie eine Reihe von Python-Skripten an und machen diese ausführbar.

user@host:~$ touch create_host.py service_discovery.py show_pending_changes.py activate_changes.py
user@host:~$ chmod +x create_host.py service_discovery.py show_pending_changes.py activate_changes.py
Befehl(e) in die Zwischenablage kopieren
Befehl(e) erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!
Bash mit curl

Die REST-API gibt alle Antworten im JSON-Format einzeilig aus. Da eine formatierte Ausgabe die Lesbarkeit doch erheblich erleichtert, wird in den folgenden Beispielen die einzeilige Ausgabe mehrzeilig formatiert dargestellt. Zur Aufbereitung des JSON-Formats gibt es diverse Websites und Werkzeuge, zum Beispiel den Kommandozeilen-JSON-Prozessor jq.

Bevor es los geht, sammeln Sie einige grundlegende Informationen, die spezifisch für Ihre Checkmk-Konfiguration sind:

Variable Beispielwert Bedeutung

HOST_NAME

myserver

Name des Checkmk-Servers

SITE_NAME

mysite

Name der Checkmk-Instanz

USERNAME

automation

Name des Automationsbenutzers

PASSWORD

theautomationsecret

Passwort des Automationsbenutzers

Diese Variablen werden im Beispiel-Code verwendet und müssen von Ihnen geändert werden, bevor Sie eine Anfrage absenden. In der obigen Tabelle finden Sie auch die Beispielwerte, die im Folgenden verwendet werden.

4.4. Anfragen stellen per Skript

Wir werden nun den Umgang mit der REST-API an einem übersichtlichen Beispiel demonstrieren: Sie erstellen einen Host mit seinen Services mit insgesamt vier Anfragen. Prinzipiell gehen Sie dabei genauso vor, wie Sie es auch mit der Checkmk-GUI tun würden:

  1. Einen Host erstellen

  2. Eine Service-Erkennung auf dem Host durchführen

  3. Die ausstehenden Änderungen anzeigen

  4. Die Änderungen aktivieren

Einen Host erstellen

Öffnen Sie die API-Dokumentation und suchen Sie im linken Navigationsbereich den Eintrag zum Erstellen eines Hosts (Create a host):

Der Eintrag in der API-Dokumentation zum Erstellen eines Hosts.
Neben allgemeinen Informationen über den gewählten Endpunkt sehen Sie konkrete Code-Beispiele zur Nutzung

Im mittleren Bereich sehen Sie die Details zur gewählten Anfrage: welche HTTP-Authentifizierung gefordert ist (diese ist identisch für alle Anfragen über die REST-API) und die notwendigen und optionalen Parameter. Notwendig (required) sind der Name des Hosts und der Ordner, in dem er angelegt werden soll. Standardmäßig wird der Host im Hauptordner (Main) erstellt. Falls Sie den Host in einem anderen Ordner anlegen wollen, müssen Sie sich eventuell zuerst über eine andere API-Anfrage (Show all folders) die existierenden Ordner anzeigen lassen, um die ID des gewünschten herauszufinden.

Im rechten Bereich sehen Sie für den aktuell sichtbaren Endpunkt den Pfad für die API-Anfrage sowie eine Reihe von Beispielanfragen (Request samples) und Beispielantworten (Response samples). Für Ihre oben vorbereiteten Skripte können Sie die passende Beispielanfrage mit einem Klick auf Copy in die Zwischenablage kopieren.

Python mit requests
Bash mit curl
Python mit requests

In der API-Dokumentation klicken Sie im rechten Beispielbereich auf den Knopf requests und dann auf Copy, um den requests-Beispiel-Code in die Zwischenablage zu kopieren. Öffnen Sie das vorbereitete Skript create_host.py und fügen Sie den Inhalt der Zwischenablage ein:

create_host.py
#!/usr/bin/env python3
import pprint
import requests

HOST_NAME = "localhost"
SITE_NAME = "checkmk"
API_VERSION = "v1"
PROTO = "http" #[http|https]
API_URL = f"{PROTO}://{HOST_NAME}/{SITE_NAME}/check_mk/api/{API_VERSION}"

USERNAME = "automation"
PASSWORD = "test123"

session = requests.session()
session.headers['Authorization'] = f"Bearer {USERNAME} {PASSWORD}"
session.headers['Accept'] = 'application/json'
session.max_redirects = 100  # increase if necessary

resp = session.post(
    f"{API_URL}/domain-types/host_config/collections/all",
    params={  # goes into query string
        "bake_agent": False,  # Tries to bake the agents for the just created hosts.
    },
    headers={
        "Content-Type": 'application/json',  # (required) A header specifying which type of content is in the request/response body.
    },
    json={
        "host_name": "example.com",
        "folder": "/",
        "attributes": {
            "ipaddress": "192.168.0.123",
        },
    },
    allow_redirects=True,
)
if resp.status_code in (200, 201):
    pprint.pprint(resp.json())
else:
    raise RuntimeError(pprint.pformat(resp.json()))
Dateiinhalt in die Zwischenablage kopieren
Dateiinhalt erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!

Im ersten Teil des Beispiel-Codes finden Sie die Umgebungsvariablen sowie die Konfiguration für die HTTP-Authentifizierung.

Darunter folgt der post-Befehl auf die Ressource, die unter dem angegebenen Pfad zu finden ist, hier also auf den REST-API-Endpunkt /domain-types/host_config/collections/all. Als Argumente des post-Aufrufs werden unter anderem die Parameter für den Request angegeben, in diesem Fall unter anderem der Name für den neu zu erzeugenden Host, der Ordner, in dem er angelegt werden soll und seine IP-Adresse.

Falls die Anfrage erfolgreich war (HTTP-Status-Code 200 oder 201), folgt nach dem post-Befehl eine einfache Ausgabe der Antwort von der API auf den Request. Andernfalls wird eine Exception geworfen, deren Beschreibung die Antwort von der API enthält.

Bash mit curl

In diesem Beispiel soll der Host myhost123 mit der IP-Adresse 192.168.0.42 im Hauptordner erstellt werden.

Beachten Sie, dass der Beispiel-Code aus der API-Dokumentation mehr Parameter enthalten kann, als Sie im konkreten Fall vielleicht benötigen. Für das aktuelle Beispiel ist dies aber nicht der Fall, und Sie müssen nur die beiden vorhandenen Parameter host_name und ipaddress ändern. Fügen Sie außerdem die richtigen Werte für die Umgebungsvariablen ein, um Ihre spezifische Checkmk-Instanz korrekt anzusteuern. Ihr angepasstes Skript sollte ungefähr so aussehen:

Python mit requests
Bash mit curl
Python mit requests
create_host.py
#!/usr/bin/env python3
import pprint
import requests

HOST_NAME = "myserver"
SITE_NAME = "mysite"
API_VERSION = "v1"
PROTO = "http" #[http|https]
API_URL = f"{PROTO}://{HOST_NAME}/{SITE_NAME}/check_mk/api/{API_VERSION}"

USERNAME = "automation"
PASSWORD = "theautomationsecret"

session = requests.session()
session.headers['Authorization'] = f"Bearer {USERNAME} {PASSWORD}"
session.headers['Accept'] = 'application/json'
session.max_redirects = 100  # increase if necessary

resp = session.post(
    f"{API_URL}/domain-types/host_config/collections/all",
    params={  # goes into query string
        "bake_agent": False,  # Tries to bake the agents for the just created hosts.
    },
    headers={
        "Content-Type": 'application/json',  # (required) A header specifying which type of content is in the request/response body.
    },
    json={
        "host_name": "myhost123",
        "folder": "/",
        "attributes": {
            "ipaddress": "192.168.0.42",
        },
    },
    allow_redirects=True,
)
if resp.status_code in (200, 201):
    pprint.pprint(resp.json())
else:
    raise RuntimeError(pprint.pformat(resp.json()))
Dateiinhalt in die Zwischenablage kopieren
Dateiinhalt erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!
Bash mit curl

Führen Sie das Skript aus:

Python mit requests
Bash mit curl
Python mit requests

Die Rückgabe des Python-Skripts ist ein Dictionary, das Sie direkt weiter verarbeiten können.

user@host:~$ python3 create_host.py
{'domainType': 'host_config',
 'extensions': {'attributes': {'ipaddress': '192.168.0.42',
                               'meta_data': {'created_at': '2026-02-16T06:36:07.848751+00:00',
                                             'created_by': 'automation',
                                             'updated_at': '2026-02-16T06:36:07.862099+00:00'}},
                'cluster_nodes': None,
                'effective_attributes': None,
                'folder': '/',
                'is_cluster': False,
                'is_offline': False},
 'id': 'myhost123',
 'links': [{'domainType': 'link',
            'href': 'http://myserver/mysite/check_mk/api/v1/objects/host_config/myhost123',
            'method': 'GET',
            'rel': 'self',
            'type': 'application/json'},
           {'domainType': 'link',
            'href': 'http://myserver/mysite/check_mk/api/v1/objects/host_config/myhost123',
            'method': 'PUT',
            'rel': 'urn:org.restfulobjects:rels/update',
            'type': 'application/json'},
           {'domainType': 'link',
            'href': 'http://myserver/mysite/check_mk/api/v1/objects/host_config/myhost123',
            'method': 'DELETE',
            'rel': 'urn:org.restfulobjects:rels/delete',
            'type': 'application/json'},
           {'domainType': 'link',
            'href': 'http://myserver/mysite/check_mk/api/v1/objects/folder_config/~',
            'method': 'GET',
            'rel': 'urn:com.checkmk:rels/folder_config',
            'title': 'The folder config of the host.',
            'type': 'application/json'},
           '... some more links...',
 'members': {},
 'title': 'myhost123'}
Befehl(e) in die Zwischenablage kopieren
Befehl(e) erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!
Bash mit curl

Im Feld extensions finden Sie Eigenschaften des neu erstellten Hosts, wie beispielsweise die von Ihnen vergebene IP-Adresse, den Ordner, in dem der Host angelegt wurde, und relevante Zeitstempel. Die Felder id und title enthalten die ID und den Host-Namen. Das Feld links enthält eine (im obigen Beispiel gekürzte) Auswahl von Anfragen, die auf den gerade erstellten Host angewendet werden können — wie es sich für eine REST-API gehört.

Eine Service-Erkennung auf dem Host durchführen

Nachdem der Host myhost123 erstellt wurde, können die dazugehörigen Services ermittelt werden. Damit eine Service-Erkennung auch tatsächlich die erwarteten Services liefert, müssen Sie zuvor auf Linux- und Windows-Hosts die jeweils passenden Agenten installieren und registrieren.

Für die Ausführung einer Service-Erkennung via REST-API wählen Sie in der API-Dokumentation den entsprechenden Eintrag aus (Execute a service discovery on a host), kopieren den Beispiel-Code in die dafür erstellte Skript-Datei und passen ihn an.

Den ersten Teil mit den Umgebungsvariablen können Sie 1:1 aus dem vorherigen Beispiel übernehmen. Im kopierten Code für die Service-Erkennung ändern Sie außerdem den Namen des Hosts zu myhost123 und bei Bedarf mit dem Parameter mode die Art der Service-Erkennung.

Python mit requests
Bash mit curl
Python mit requests
service_discovery.py
#!/usr/bin/env python3
import pprint
import requests

HOST_NAME = "myserver"
SITE_NAME = "mysite"
API_VERSION = "v1"
PROTO = "http" #[http|https]
API_URL = f"{PROTO}://{HOST_NAME}/{SITE_NAME}/check_mk/api/{API_VERSION}"

USERNAME = "automation"
PASSWORD = "theautomationsecret"

session = requests.session()
session.headers['Authorization'] = f"Bearer {USERNAME} {PASSWORD}"
session.headers['Accept'] = 'application/json'
session.max_redirects = 100  # increase if necessary

resp = session.post(
    f"{API_URL}/domain-types/service_discovery_run/actions/start/invoke",
    headers={
        "Content-Type": 'application/json',  # (required) A header specifying which type of content is in the request/response body.
    },
    json={
        "host_name": "myhost123",
        "mode": "refresh",
    },
    allow_redirects=True,
)
if resp.status_code in (200, 201):
    pprint.pprint(resp.json())
elif resp.status_code == 204:
    print('Done')
elif resp.status_code == 303:
    print('Redirected to', resp.headers['location'])
else:
    raise RuntimeError(pprint.pformat(resp.json()))
Dateiinhalt in die Zwischenablage kopieren
Dateiinhalt erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!
Bash mit curl

Führen Sie auch dieses Skript aus:

Python mit requests
Bash mit curl
Python mit requests
user@host:~$ python3 service_discovery.py
Done
Befehl(e) in die Zwischenablage kopieren
Befehl(e) erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!

Wenn die gewünschte Service-Erkennung mit den angegebenen Werten möglich ist, wird die Erkennung als Hintergrundauftrag angestoßen. Sie werden an einen anderen Endpunkt der API weitergeleitet (redirect), der im Erfolgsfall den HTTP-Status-Code 204 zurückgibt. Dieser Code informiert Sie darüber, dass die Aktion erfolgreich war und planmäßig keine inhaltliche Antwort von der API erfolgt ist.

Bash mit curl

Die ausstehenden Änderungen anzeigen

Vor der Aktivierung der Änderungen ist noch ein Zwischenschritt notwendig: die Anzeige der ausstehenden Änderungen mit der Anfrage Show all pending changes. Zusätzlich zu den Änderungen, die sich angesammelt haben, liefert die REST-API dabei das HTTP ETag (entity tag), das Sie benötigen, um diese Änderungen zu aktivieren. Die Änderung eines Objekts via REST-API erfolgt nicht über die ID oder den Titel des Objekts. Stattdessen wird das generierte ETag genutzt, mit dem verhindert werden soll, dass mehrere konkurrierende Anfragen Werte desselben Objekts gegenseitig überschreiben.

Das ETag wird im Antwort-Header (response header) zurückgeliefert. Passen Sie daher den Beispiel-Code aus der API-Dokumentation so an, dass der Header vollständig mit ausgegeben wird:

Python mit requests
Bash mit curl
Python mit requests

Auch hier müssen Sie wieder einige Zeilen ändern, um Ihren Checkmk-Server, Ihre Instanz und die richtigen Zugangsdaten anzugeben. Ergänzen Sie außerdem zwei Zeilen mit print/pprint-Befehlen, um ein Python-Dictionary mit allen Header-Informationen und den HTTP-Status-Code ausgeben zu lassen.

show_pending_changes.py
#!/usr/bin/env python3
import pprint
import requests

HOST_NAME = "myserver"
SITE_NAME = "mysite"
API_VERSION = "v1"
PROTO = "http" #[http|https]
API_URL = f"{PROTO}://{HOST_NAME}/{SITE_NAME}/check_mk/api/{API_VERSION}"

USERNAME = "automation"
PASSWORD = "theautomationsecret"

session = requests.session()
session.headers['Authorization'] = f"Bearer {USERNAME} {PASSWORD}"
session.headers['Accept'] = 'application/json'

resp = session.get(
    f"{API_URL}/domain-types/activation_run/collections/pending_changes",
)

pprint.pprint(dict(resp.headers))
print("xxx-status_code={}".format(resp.status_code))

if resp.status_code == 200:
    pprint.pprint(resp.json())
else:
    raise RuntimeError(pprint.pformat(resp.json()))
Dateiinhalt in die Zwischenablage kopieren
Dateiinhalt erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!
Bash mit curl

Nach der Ausführung des Skripts werden in der Ausgabe nun zuerst die Header-Zeilen gezeigt. Die Beispiel-Ausgaben hier sind gekürzt. Hervorgehoben sind das ETag im Header, die Attribute der zwei ausstehenden Änderungen (Host anlegen und Service-Erkennung durchführen) und der HTTP-Status-Code.

Python mit requests
Bash mit curl
Python mit requests
user@host:~$ python3 show_pending_changes.py
{...
 'Content-Type': 'application/json',
 'Date': 'Mon, 16 Feb 2026 13:35:57 GMT',
 'ETag': '"3b3389f4d4f6a73603831ac1d0caf973f48cd88001c80a4ff1cd4caf90787879"',
 ...
}
xxx-status_code=200
{'domainType': 'activation_run',
 ...,
 'value': [{'action_name': 'create-host',
            'id': 'b4790ffb-ac89-4559-8a8c-d0c5f69a8c57',
            'text': 'Created new host myhost123.',
            'time': '2026-02-16T13:23:40.287288+00:00',
            'user_id': 'automation'},
           {'action_name': 'refresh-autochecks',
            'id': '551b32be-d3ce-4d94-add7-f38b7fa7fb42',
            'text': 'Refreshed check configuration of host '
                    ''myhost123'',
            'time': '2026-02-16T13:23:48.391117+00:00',
            'user_id': 'automation'}]}
Befehl(e) in die Zwischenablage kopieren
Befehl(e) erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!
Bash mit curl

Das ETag benötigen Sie im nächsten und letzten Schritt.

Die Änderungen aktivieren

Zum Abschluss müssen die Änderungen aktiviert werden. Die passende Anfrage heißt Activate pending changes.

Kopieren Sie den Code aus der API-Dokumentation, ändern Sie die Header-Zeile If-Match und setzen Sie dort das im vorherigen Abschnitt ausgelesene ETag ein. Im Datenteil geben Sie für den Parameter sites den Namen der Instanz ein — dort, wo die Änderungen aktiviert werden sollen.

Python mit requests
Bash mit curl
Python mit requests
activate_changes.py
#!/usr/bin/env python3
import pprint
import requests

HOST_NAME = "myserver"
SITE_NAME = "mysite"
API_VERSION = "v1"
PROTO = "http" #[http|https]
API_URL = f"{PROTO}://{HOST_NAME}/{SITE_NAME}/check_mk/api/{API_VERSION}"

USERNAME = "automation"
PASSWORD = "theautomationsecret"

session = requests.session()
session.headers['Authorization'] = f"Bearer {USERNAME} {PASSWORD}"
session.headers['Accept'] = 'application/json'
session.max_redirects = 100  # increase if necessary

resp = session.post(
    f"{API_URL}/domain-types/activation_run/actions/activate-changes/invoke",
    headers={
        "If-Match": '"3b3389f4d4f6a73603831ac1d0caf973f48cd88001c80a4ff1cd4caf90787879"',  # (required) The value of the, to be modified, object's ETag header.
        "Content-Type": 'application/json',  # (required) A header specifying which type of content is in the request/response body.
    },
    json={
        "redirect": False,
        "sites": ["mysite"],
        "force_foreign_changes": False,
    },
    allow_redirects=True,
)
if resp.status_code in (200, 201):
    pprint.pprint(resp.json())
elif resp.status_code == 204:
    print('Done')
elif resp.status_code == 303:
    print('Redirected to', resp.headers['location'])
else:
    raise RuntimeError(pprint.pformat(resp.json()))
Dateiinhalt in die Zwischenablage kopieren
Dateiinhalt erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!
Bash mit curl

Führen Sie das Skript aus:

Python mit requests
Bash mit curl
Python mit requests
user@host:~$ python3 activate_changes.py
{'domainType': 'activation_run',
 'extensions': {'changes': [{'action_name': 'create-host',
                             'id': 'b4790ffb-ac89-4559-8a8c-d0c5f69a8c57',
                             'text': 'Created new host myhost123.',
                             'time': '2026-02-16T13:23:40.287288+00:00',
                             'user_id': 'automation'},
                            {'action_name': 'refresh-autochecks',
                             'id': '551b32be-d3ce-4d94-add7-f38b7fa7fb42',
                             'text': 'Refreshed check configuration of host '
                                     ''myhost123'',
                             'time': '2026-02-16T13:23:48.391117+00:00',
                             'user_id': 'automation'}],
                'force_foreign_changes': False,
                'is_running': True,
                'sites': ['mysite'],
                'time_started': '2026-02-16T14:00:37.029962+00:00'},
 'id': 'c123e01b-95ab-4898-b12e-859193ea30f5',
 'links': [{'domainType': 'link',
            'href': 'http://myserver/mysite/check_mk/api/v1/objects/activation_run/c123e01b-95ab-4898-b12e-859193ea30f5',
            'method': 'GET',
            'rel': 'self',
            'type': 'application/json'},
           {'domainType': 'link',
            'href': 'http://myserver/mysite/check_mk/api/v1/objects/activation_run/c123e01b-95ab-4898-b12e-859193ea30f5/actions/wait-for-completion/invoke',
            'method': 'GET',
            'rel': 'urn:com.checkmk:rels/wait-for-completion',
            'type': 'application/json'}],
 'members': {},
 'title': 'Activation status: In progress.'}
Befehl(e) in die Zwischenablage kopieren
Befehl(e) erfolgreich in die Zwischenablage kopiert!
Schreibzugriff auf die Zwischenablage wurde verweigert!
Bash mit curl

Der Text im title zeigt, dass die Aktivierung gestartet wurde. Wieder schlägt die REST-API unter links zwei sinnvolle Folgeanfragen vor: um den Status dieser Aktivierung abzufragen und auf deren Abschluss zu warten.

Werfen Sie zum Abschluss einen Blick in die Weboberfläche Ihrer Checkmk-Instanz. Wenn alle Skripte ohne Fehler durchgelaufen sind, sollten Sie dort Folgendes sehen:

  • Der Host mit dem Namen myhost123 und der IP-Adresse 192.168.0.42 existiert im obersten Ordner im Setup.

  • Für diesen Host sind einige Services bekannt. Welche dies sind, hängt davon ab, welche Art Objekt sich hinter der verwendeten IP-Adresse verbirgt.

  • Alle vorbereiteten Änderungen sind aktiviert, oder die Aktivierung läuft noch. Nach erfolgter Aktivierung sehen Sie den Host und die dazugehörigen Services im Monitoring.

4.5. Anfragen stellen mit der interaktiven GUI der REST-API

Zusätzlich zur ausführlichen Dokumentation der REST-API, die oben vorgestellt wurde, wird noch eine weitere Ressource aus der Spezifikation der API erzeugt: die interaktive GUI der REST-API, die einen direkten API-Zugriff auf die Checkmk-Instanz aus dem Browser heraus ermöglicht. Die interaktive GUI wird mit Swagger erzeugt und ist im Hilfe-Menü Ihrer Checkmk-Instanz verlinkt.

Die interaktive GUI ist genau auf Ihre Instanz von Checkmk zugeschnitten — und somit kann sie auch nur innerhalb von Ihrer Umgebung genutzt werden.

In der interaktiven GUI können Sie einzelne Anfragen an konkrete API-Endpunkte Ihrer Checkmk-Instanz mit Parameterwerten füllen und abschicken. Die GUI verpackt Ihre Eingaben in Curl-Anfragen, die an Ihre Instanz geschickt werden. Daraufhin erhalten Sie direkt in der interaktiven GUI die übersichtlich aufbereitete Antwort der REST-API auf diese Anfrage.

Da bestimmte Endpunkte nicht in isolierter Form ohne Kontext angesprochen werden können, bildet die interaktive GUI nur eine Teilmenge der API-Funktionalität ab.

Sie öffnen die interaktive GUI aus der Checkmk-GUI über die Navigationsleiste im Menü Help > Developer resources > REST API > Version 1 > Interactive GUI. Die interaktive GUI wird in einem neuen Browser-Fenster (bzw. Browser-Tab) angezeigt:

Der Eintrag in der interaktiven GUI der REST-API zum Erstellen eines Hosts.
Mit Try it out haben Sie die Möglichkeit, die vorbereiteten API-Anfragen um eigene Werte zu ergänzen und sie dann abzuschicken

Im Folgenden skizzieren wir, wie Sie die erste Anfrage aus dem obigen Beispiel (einen Host erstellen) statt per Skript auch mit der interaktiven GUI der REST-API ausführen können:

  1. Authentisieren: Die interaktive GUI bietet nach dem Anklicken des Knopfs Authorize (auf der rechten Seite über dem Eintrag des ersten Endpunkt-Ordners) eine Dialogbox zur Eingabe der Authentifizierungsinformationen. Sofern Sie in der Weboberfläche von Checkmk als Benutzer angemeldet sind, brauchen Sie dort aber keine Eingaben zu machen, da Sie als Checkmk-Benutzer per Cookie-Authentifizierung berechtigt zur Nutzung der REST-API sind. Ihnen stehen dann alle Funktionen der API zur Verfügung, für die Ihr Benutzerkonto die benötigten Berechtigungen hat.

  2. Endpunkt auswählen: Wählen Sie im Ordner Hosts den Endpunkt Create a host aus und klicken Sie Try it out.

  3. Parameterwerte eingeben: Überschreiben Sie im Request body den Beispielwert für host_name. Im Feld attributes: {} können Sie die gewünschte IP-Adresse einfügen: "ipaddress": "192.168.0.42".

  4. Anfrage senden: Klicken Sie Execute.

  5. Antwort überprüfen: Unter Responses sehen Sie zunächst das gesendete Curl-Kommando und die URL des Endpunkts. Darunter wird unter Server response die Antwort angezeigt mit HTTP-Status-Code und in Details die (mehrzeilig formatierte) REST-API Antwort.

Die interaktive GUI der REST-API bietet Ihnen also die Möglichkeit, schnell und unkompliziert die Funktionen der API auszuprobieren und sich mit den Details der Eingabewerte und mit konkreten Antworten vertraut zu machen.

4.6. API-Antworten bei Problemen

Bei erfolgreichen API-Anfragen erhalten Sie von der API als Antwort den passenden HTTP-Status-Code sowie ein JSON-Objekt, das die Ergebnisse der Anfrage beschreibt. Der Zugriff auf diese Werte kann sich in verschiedenen Frameworks unterscheiden. So greifen Sie beispielsweise in den oben gezeigten Beispielen mit requests via resp.status_code auf den HTTP-Status-Code zu und via resp.json() auf das von der REST-API zurückgegebene JSON-Objekt.

Einen Sonderfall stellt der HTTP-Status-Code 204 dar, der besagt, dass eine Anfrage zwar erfolgreich war, aber planmäßig zu keiner Antwort geführt hat. Logischerweise kann auch resp.json() in diesem Fall keinen Wert enthalten.

Auch bei fehlgeschlagenen Anfragen lohnt sich ein Blick in das JSON-Objekt, das die API zurückgibt. Hier können Sie hilfreiche Informationen ablesen, die Ihnen helfen, dem zugrundeliegenden Problem auf die Spur zu kommen:

{
  "detail": "There are changes from other users and foreign changes are not allowed in this API call.",
  "status": 401,
  "title": "The operation has failed."
}

Je nach Fehler können die in der Ausgabe angezeigten Parameter unterschiedlich sein. Immer erhalten Sie aber — wie auch bei erfolgreichen Anfragen — in status den HTTP-Status-Code und in title eine Kurzbeschreibung der Rückmeldung von der API.

In den meisten Fällen zeigt Ihnen detail, wie der Name schon vermuten lässt, detaillierte Informationen an. Im obigen Beispiel erfahren Sie, dass es zwar ausstehende Änderungen in Checkmk gibt, diese aber nicht mit der durchgeführten API-Anfrage aktiviert werden dürfen. Über die API können standardmäßig nur Änderungen aktiviert werden, die erstens auch über die API durchgeführt wurden und zweitens vom gleichen Benutzer stammen wie dem, der die Aktivierung via API ausführt. Sie können dieses Verhalten durch explizites Setzen des Felds force_foreign_changes auf True überschreiben.

Auch im nächsten Beispiel stecken die hilfreichen in den detaillierten Informationen:

{
  "detail": "These fields have problems: host_name",
  "fields": {
    "host_name": [
      "'my/host' does not match pattern '^[-0-9a-zA-Z_.]+\\\\Z'."
    ]
  },
  "status": 400,
  "title": "Bad Request"
}

Hier liegt das Problem darin, dass ein Parameterwert sich nicht an den gültigen Wertebereich hält (wegen eines Schrägstrichs im Host-Namen).

In diesem Handbuchartikel sollen nicht sämtliche möglichen Fehler von API-Anfragen aufgelistet werden. An den gezeigten Beispielen sehen Sie aber, dass die REST-API in der Ausgabe meist genügend Informationen über die Ursache liefert und Ihnen so Anhaltspunkte für den Einstieg in die Analyse und die Fehlerbehebung gibt.

5. Die unstable-Version der API nutzen

Im Entwicklungszyklus von Checkmk kommt es gelegentlich vor, dass Korrekturen für bestehende Features auch in Patch Releases für ältere, noch im Support-Zeitraum befindliche Major-Versionen von Checkmk zurückportiert werden. In solchen Fällen werden die entsprechenden Änderungen aber nicht in älteren Versionen der REST-API zur Verfügung gestellt.

Damit Sie dennoch Zugriff auf derartige Backports haben, liefert Checkmk ab Version 2.5.0 die REST-API nicht nur in allen unterstützten Versionen (z.B. v1) aus, sondern zusätzlich in einer weiteren, nicht unterstützten Version namens unstable. Sie erhalten also auf diese Weise bei Patch-Updates Zugriff auf bestimmte Änderungen an der REST-API, die nicht in den unterstützten REST-API-Versionen Ihrer Checkmk-Version enthalten sind.

Die unstable-Version der REST-API kann auch neue, experimentelle Features enthalten. Betrachten Sie die unstable-Version in diesem Fall als Testlabor für Features, die in einem baldigen Release vollständig unterstützt werden.

Important

Wie der Name schon andeutet, gilt für die Funktionalität der REST-API in der unstable-Version keine Garantie und kein Anspruch auf Support. Experimentelle Endpunkte können jederzeit und ohne Vorwarnung geändert oder abgeschaltet werden. Im produktiven Betrieb sollten Sie immer nur Endpunkte der REST-API ansteuern, die zu einer von Ihrer Checkmk-Instanz unterstützten Version der REST-API gehören!

Der Umfang und genaue Inhalt der unstable-Version unterscheidet sich zwischen Major-Versionen von Checkmk. Um zu erfahren, welche Endpunkte Sie für eine konkrete Checkmk-Instanz über die unstable-Version der REST-API nutzen können, lohnt sich ein erneuter Blick in das Menü unter Help > Developer resources > REST API:

Help-Menü in der Navigationsleiste.
Im Help-Menü zur REST-API finden Sie auch Ressourcen zur unstable-Version

Hier können Sie zu Unstable > Documentation navigieren und die Dokumentation nutzen wie gewohnt. Die interaktive GUI der REST-API ist für die unstable-Version der REST-API nicht verfügbar.

In der Dokumentation für die unstable-Version gibt es einige Endpunkte, deren Verhalten von dem in der aktuell unterstützten Major-Version der REST-API abweicht. Diese Endpunkte sind auf zweifache Weise zu erkennen:

  • Als Wert für API_VERSION wird in den Code-Beispielen, die zum Endpunkt gehören, der String unstable angegeben. Bei Endpunkten, deren Verhalten identisch ist zu ihrem Gegenstück in der unterstützten Major-Version, wird v1 als Version angegeben.

  • Die Beschreibung des Endpunktes beginnt mit dem Hinweis NEW: This endpoint is new in this API version. oder CHANGED: This endpoint has been modified in this API version.

6. Die API absichern

Da beim Zugriff über die REST-API sensible Daten übertragen und — je nach Berechtigung des Automationsbenutzers — umfassende Änderungen an Checkmk durchgeführt werden können, sollten Sie den Zugriff entsprechend absichern. Hier finden Sie einige der Möglichkeiten:

  • Checkmk über HTTPS: Nutzen Sie die API ausschließlich über das Hypertext Transfer Protocol Secure (HTTPS), da Benutzername, Passwort und auch Konfigurationsdaten sonst im Klartext im Netz übertragen werden.

  • Geben Sie dem Automationsbenutzer ein Passwort mit einer ausreichenden Länge. Da das Passwort in der Regel nur in einem Skript hinterlegt wird, können Sie problemlos ein sehr langes und komplexes vergeben.

  • Achten Sie auf das Berechtigungskonzept zu den Skripten, mit denen Sie die Anfragen an die API stellen. In den Skripten können sensible Daten, wie Konfigurationsdaten, Passwörter usw. enthalten sein. Stellen Sie daher sicher, dass ausschließlich berechtigte Benutzer und Gruppen diese Skripte lesen können.


Letzte Änderung: Wed, 29 Apr 2026 15:27:00 GMT via Commit c8143abd7
Auf dieser Seite