Die Audit Logs API kann verwendet werden, um:
- Workspace-Aktivitätsdaten in dein SIEM oder andere Monitoring-Tools einzuspeisen
- Änderungen in deiner Organisation nachzuverfolgen, von Workspace-Einstellungen und Model Keys bis hin zu Rollenänderungen, fehlgeschlagenen Anmeldeversuchen und mehr
- Eigene Dashboards und Berichte für Workspace-Aktivitäten zu erstellen
Voraussetzungen
Um die Audit Logs API zu nutzen, benötigst du:
- Workspace Admin-Berechtigung: Nur Workspace-Administratoren können API-Schlüssel mit Audit-Log-Berechtigungen erstellen.
- API-Schlüssel mit
AUDIT_LOG_API Scope: Dein API-Schlüssel muss den dedizierten Audit-Log Scope aktiviert haben.
Wichtiger Sicherheitshinweis: Nutzer mit Zugriff auf einen API-Schlüssel mit dem AUDIT_LOG_API Scope können alle Audit-Log-Daten des Workspaces einsehen, einschließlich IP-Adressen, Nutzeraktionen und Konfigurationsänderungen. Gewähre diese Berechtigung nur vertrauenswürdigen Nutzern.
Aufbewahrung
Audit-Log-Einträge werden 90 Tage lang aufbewahrt. Stelle sicher, dass du alle benötigten Daten exportierst oder weiterleitest, bevor sie ablaufen.
Verfügbarer Endpunkt
GET /api/audit-logs/{workspace_id}
Authentifizierung
Alle API-Anfragen erfordern Bearer-Token-Authentifizierung:
Authorization: Bearer YOUR_API_KEY
Der Audit-Log-Eintrag
Jeder Audit-Log-Eintrag beschreibt einen Akteur, der eine Aktion auf einer Entität ausführt. Hier ist, was jeder Eintrag enthält:
| Feld | Beschreibung |
|---|
actor_id, actor_type, actor_name | Wer die Aktion ausgeführt hat. Akteur-Typen: USER, API_KEY, SYSTEM, SCIM |
action | Was passiert ist, in Punkt-Notation (z.B. user.updated, workspace.created, api_keys.deleted) |
entity_type, entity_id | Welche Ressource betroffen war (z.B. User, Workspace, Group, IntegrationConnection) |
created_at | Wann das Ereignis stattfand |
ip_address, user_agent | Woher die Anfrage kam |
changes | Ein before/after-Diff der geänderten Felder (bei Update-Ereignissen) |
snapshot | Vollständiger Entity-Snapshot oder zusätzliche Event-Metadaten (z.B. bei Delete-/Create-Ereignissen oder zusätzlicher Kontext wie fehlgeschlagene Login-Details) |
next_cursor-Feld — übergib es als cursor-Query-Parameter in deiner nächsten Anfrage, um die nächste Seite zu erhalten. Wenn next_cursor null ist, hast du das Ende erreicht.
# Erste Anfrage
curl "https://api.langdock.com/api/audit-logs/{workspace_id}?limit=50" \
-H "Authorization: Bearer YOUR_API_KEY"
# Nächste Seite
curl "https://api.langdock.com/api/audit-logs/{workspace_id}?limit=50&cursor={next_cursor}" \
-H "Authorization: Bearer YOUR_API_KEY"
Filtern
Du kannst Ergebnisse mit Query-Parametern eingrenzen:
| Parameter | Typ | Beschreibung |
|---|
from | datetime | Beginn des Zeitraums (ISO 8601) |
to | datetime | Ende des Zeitraums (ISO 8601) |
entity_type | string | Nach Entity-Typ filtern (z.B. User, Workspace) |
actor_id | uuid | Nach dem Akteur filtern, der die Aktion ausgeführt hat |
limit | integer | Einträge pro Seite (Standard 50, Maximum 50) |
cursor | uuid | Cursor aus der vorherigen Antwort für Pagination |
Fehlerbehandlung
| Statuscode | Beschreibung |
|---|
400 | Ungültige Anfrageparameter (z.B. fehlerhaftes Datum, ungültige UUID) |
401 | Fehlender oder ungültiger API-Schlüssel |
403 | API-Schlüssel hat keinen AUDIT_LOG_API Scope, oder workspace_id stimmt nicht überein |
429 | Rate Limit überschritten — warte kurz und versuche es erneut |
500 | Interner Serverfehler |
Langdock blockiert bewusst Browser-basierte Anfragen, um deinen API-Schlüssel zu schützen und die Sicherheit deiner Anwendungen zu gewährleisten. Weitere Informationen findest du in unserem Guide zu Best Practices für API-Schlüssel. 
