Öffentliche Kabeen-API

Eine REST-API, um das IT-Asset-Inventar Ihres Workspace aus Ihren eigenen Tools und Skripten zu lesen und zu verwalten

Die öffentliche Kabeen-API ist eine REST-API für Integrationen, die das IT-Asset-Inventar eines Workspace lesen oder verwalten müssen — Anwendungen, Server, Netzwerke, Router, Arbeitsplatzrechner, Datenobjekte, Verträge, Organisationsstruktur, Personen, Ankündigungen und Audit-Verlauf. Sie ist für externe Werkzeuge konzipiert: CMDB-Synchronisationen, eigene Dashboards, ITSM-Anbindungen, Reporting-Pipelines und interne Automatisierungsskripte, die programmatischen Zugriff auf dieselben Daten benötigen, die ein Admin im Kabeen-Produkt sieht.

Dies ist Version 1.0.0, die erste öffentliche Version der API.

Basis-URL und Versionierung

https://app.kabeen.io/public/v1

Ersetzen Sie app.kabeen.io durch Ihren eigenen Host, wenn Sie Kabeen selbst hosten. Das Pfadsegment v1 ist die API-Version: Breaking Changes erscheinen unter einem neuen Versionspräfix, statt v1 nachträglich zu verändern.

Alle Request- und Response-Bodies sind JSON. Alle Endpunkte lesen und schreiben über genau einen Workspace — den, an den der API-Schlüssel gebunden ist. Es gibt keine Möglichkeit, mit demselben Schlüssel einen anderen Workspace anzusprechen.

Authentifizierung

Jede Anfrage wird mit einem Workspace-gebundenen API-Schlüssel authentifiziert, übermittelt entweder als Authorization: Bearer kbn_live_... oder als X-Api-Key: kbn_live_.... Der Workspace ist an den Schlüssel selbst gebunden — er wird nie im Pfad oder im Request-Body übergeben.

Schlüssel tragen einen Satz von Berechtigungs-Scopes (z. B. applications:read, contracts:add), und jeder Endpunkt dokumentiert den exakten Scope, den er erfordert. Rufen Sie GET /public/v1/me auf, um einen Schlüssel zu introspektieren: Der Aufruf liefert den Workspace, zu dem der Schlüssel gehört, die Metadaten des Schlüssels selbst und die von ihm gewährten Scopes.

Der vollständige Leitfaden — einschließlich der Ausstellung, Rotation und des Widerrufs von Schlüsseln — steht unter Authentifizierung.

Ressourcenbereiche

Die API ist in die folgenden Ressourcenbereiche gegliedert, mit insgesamt rund 200 Operationen:

BereichBeschreibungPrimäre(r) Scope(s)
IntrospektionBeschreibt den vorgelegten API-Schlüssel: Workspace, Metadaten, gewährte Scopes.jeder gültige Schlüssel
AnwendungenAnwendungsinventar, ausführliche Details und Unterressourcen (Nutzung, Flüsse, Technologien, Verträge, Kommentare, Verantwortliche, Tags, Teams, Lebenszyklus, Dokumente, benutzerdefinierte Felder, Experience-Metriken, funktionale Fähigkeiten).applications:read / :add / :edit / :delete / :comment
ServerManuell erfasste und von Agenten gemeldete Infrastruktur-Server, mit Verantwortlichen, Tags, Schnittstellen, Metriken und verknüpften Anwendungen.infrastructure:read / :add / :edit / :delete
NetzwerkeNetzwerke und ihre verbundenen Router.infrastructure:read / :add / :edit / :delete
RouterNetzwerkgeräte — Router, Firewall, Switch, Access Point.infrastructure:read / :add / :edit / :delete
Arbeitsplatzrechner & SoftwareVon Agenten gemeldete Arbeitsplatzrechner, installierte Programme, Software-Inventar und Agent-Deployment-Status.infrastructure:read, agents:read
DatenDatenobjekte (Informationswerte) und ihre Verknüpfungen zu Anwendungen.data:read / :add / :edit / :delete
KatalogSuche im globalen Anwendungskatalog und automatisch entdeckte Anwendungen.applications:read
VerträgeAnwendungsverträge, workspace-weit zusammengeführt.contracts:read / :add / :edit / :delete
TaxonomieAnwendungskategorien und Tags.categories:*, tags:*
OrganisationOrganisationsbaum und Teams (Geschäftseinheiten).organisation:read / :add / :edit / :delete
PersonenErfasste Endnutzer (mit Experience-Metriken) und Workspace-Mitglieder.users:read, members:read
WorkspaceDer Workspace (Tenant), an den der Schlüssel gebunden ist.tenant:read / :edit
AnkündigungenWorkspace-Ankündigungen.announces:read / :add / :edit / :delete
Audit-LogWorkspace-Audit-Ereignisse, cursor-paginiert.audit_log:read
Dashboards, Insights & DiagrammeAggregierte Dashboards (Finanzen, Nutzung, Betrieb, Architektur, Technologie, Arbeitsplatzrechner), Health-Insights und Architekturdiagramme.*_dashboard:read, *_diagram:read, applications:read

Die vollständige Liste der Endpunkte mit ihren Ein- und Ausgaben finden Sie in der Endpunkt-Referenz.

Konventionen

  • Überall JSON — jeder Request- und Response-Body ist JSON (application/json).
  • UUIDs und Datumsangaben als Strings — Ressourcen-Ids sind UUID-Strings; Datumsangaben und Zeitstempel sind ISO-8601-Strings.
  • Offset-Paginierung — Listen-Endpunkte akzeptieren limit (1–200, Standard 50) und offset (Standard 0) und liefern einen Umschlag der Form { "data": [...], "pagination": { "limit", "offset", "total" } }. Die einzige Ausnahme ist das Audit-Log, das cursor-basiert paginiert. Siehe Paginierung und Fehler.
  • Einheitliche Fehler — jeder 4xx/5xx-Response-Body hat dieselbe Form: { "code", "message", "status" }.
  • Auditiert — jeder öffentliche API-Aufruf wird in das Audit-Log des Workspace geschrieben, mit dem API-Schlüssel als Akteur.
  • Keine Webhooks — die API ist in dieser Version ausschließlich Polling-basiert; es gibt keinen Event-/Webhook-Mechanismus. Das Audit-Log kommt einem Änderungs-Feed am nächsten — Hinweise zum Polling finden Sie unter Paginierung und Fehler.

Öffentliche API oder MCP-Server?

Beide Schnittstellen stellen die Karte des Workspace bereit. Wählen Sie nach dem Konsumenten:

  • Die öffentliche API (dieser Abschnitt) ist für deterministische, programmatische Integrationen gedacht — Skripte, Synchronisationen, Pipelines. Sie authentifiziert sich mit einem API-Schlüssel, der als Service-Identität agiert.
  • Der MCP-Server ist für KI-Assistenten und -Agenten gedacht. Er authentifiziert sich über OAuth als menschliches Mitglied und erbt dessen Berechtigungen.

Nächste Schritte