Entwickler

MCP-Server und REST-API

KI-Agenten und eigene Systeme brauchen keinen Browser, sondern eine Schnittstelle mit denselben Regeln wie die Oberfläche: dieselben Berechtigungen, dieselbe Mandantentrennung, dieselbe Regel „jede KI-Ausgabe bleibt Entwurf".

Zwei Wege, ein Regelwerk

Beide Schnittstellen laufen über denselben Dienst und dieselbe Schlüsselprüfung. Was ein Agent über MCP darf, darf er auch über REST — nicht mehr.

MCP-Server: https://workspace.reportact.com/api/mcp
REST-Basisadresse: https://workspace.reportact.com/api/v1
OpenAPI-Beschreibung: /api/v1/openapi.json
Anmeldung: API-Schlüssel im Authorization-Kopf als Bearer-Token. Für MCP zusätzlich die Berechtigung mcp:connect.
Drossel: 120 Aufrufe je Minute und Schlüssel, für REST und MCP gleichermaßen. Darüber 429 mit Retry-After.

MCP

Fünfzehn Werkzeuge für Ihre Werkbank

Jede Werkbank mit Model Context Protocol (Claude, Copilot, eigene Anwendung) verbindet sich mit der Adresse oben und arbeitet im Namen Ihrer Organisation.

Lieferanten

Register lesen, Lieferanten anlegen und ändern, die Aufnahme starten und ihren Fortschritt verfolgen, eine Risikobewertung anstoßen.

Verträge

Verträge anlegen und Dokument mitgeben; die Prüfung der 47 DORA-Art.-30-Klauseln läuft danach automatisch.

Vorfälle und Nachweise

Vorfälle melden, Sicherheitsereignisse einspeisen, Nachweise einreichen — jeder versiegelt und ohne Login prüfbar.

Kontrollen und Fristen

Erfüllungsgrad je Control lesen, offene Feststellungen und anstehende Meldefristen abfragen.

Nachweisstrom

Ein Agent erhält seine Quittung vor der Wirkung. Fehlt ein Glied, ist die Lücke beweisbar.

Die verbindliche Liste der Werkzeuge und Berechtigungen steht in der Anwendung: Werkzeuge und Berechtigungen ansehen

REST-API

Sechzehn Endpunkte, eine Beschreibung

Dieselbe Fachlogik, ohne MCP-Werkbank. Verbindliche Quelle ist die maschinenlesbare Beschreibung unter /api/v1/openapi.json; die Tabelle ist ihr Inhaltsverzeichnis.

Methode	Pfad	Berechtigung	Wofür
GET	`/v1/me`	—	Wer bin ich: Organisation, Einrichtung, Berechtigungen dieses Schlüssels
GET	`/v1/vendors`	`vendors:read`	Lieferantenregister lesen
POST	`/v1/vendors`	`vendors:write`	Lieferant anlegen (Entwurf)
GET	`/v1/vendors/{id}`	`vendors:read`	Einen Lieferanten lesen
PATCH	`/v1/vendors/{id}`	`vendors:write`	Einen Lieferanten ändern
POST	`/v1/contracts`	`contracts:write`	Vertrag anlegen (Entwurf)
POST	`/v1/contracts/{id}/document`	`contracts:write`	Dokument an einen Vertrag hängen — stößt die Klauselprüfung an
POST	`/v1/incidents`	`incidents:write`	Vorfall melden (Entwurf)
POST	`/v1/events`	`events:ingest`	Sicherheitsereignis einspeisen
POST	`/v1/evidence`	`evidence:write`	Nachweis einreichen — wird sofort versiegelt
GET	`/v1/controls`	`controls:read`	Erfüllungsgrad je Control lesen
POST	`/v1/assessments/vendors`	`assessments:run`	Risikobewertung anstoßen
GET	`/v1/assessments/vendors/status`	`assessments:run`	Stand der Bewertungsläufe
POST	`/v1/agent-events`	`evidence:stream`	Agenten-Ereignis in den Nachweisstrom
GET	`/v1/agent-events/{id}/receipt`	`evidence:stream`	Quittung zu einem Ereignis
GET	`/v1/agent-streams/{key}`	`evidence:stream`	Strom eines Agenten lesen
GET	`/v1/openapi.json`	—	Die Beschreibung selbst, maschinenlesbar

Fehler

Jeder Fehler kommt in derselben Hülle: { "error": { "code", "message" }, "requestId" }, dazu der Kopf X-Request-Id. Ein 401 ist für jeden Ablehnungsgrund gleich. Fehlt eine Berechtigung, kommt 403 mit dem fehlenden Namen, nie eine stillschweigend gekürzte Antwort.

Referenz

Jeder Endpunkt, mit Antwort

Aufklappen zeigt Berechtigung, Anfragerumpf und jede mögliche Antwort mit Beispiel, erzeugt aus /api/v1/openapi.json.

Beschreibung wird geladen …

Die Regeln

Was ein Agent nicht kann

Nichts freigeben

Lieferantenfreigabe, Bestätigung einer Aufnahme und Meldung an eine Behörde bleiben beim Menschen.

Nicht über die Gesellschaft hinaus

Ein Schlüssel gehört genau einer Gesellschaft. Datensätze einer anderen sind „nicht gefunden", nie „verboten".

Nicht mehr als sein Scope

Dreizehn Berechtigungen, einzeln vergeben. Ein Lese-Schlüssel für Lieferanten kann keine Nachweise einreichen.

Nicht unbeobachtet

Jeder Aufruf steht im WORM-Protokoll, mit der Schlüsselkennung als Akteur. Es ist append-only, dreifach erzwungen.

Eine Ausnahme

Ein eingereichter Nachweis wird sofort versiegelt — Hash-Kette, Signatur und Zeitstempel in einem Schritt, unumkehrbar. Ein Fehler lässt sich nur durch einen späteren, verketteten Eintrag richtigstellen.

Loslegen

In drei Schritten verbunden

Schlüssel anlegen — In der Anwendung unter Einstellungen → API. Wählen Sie nur die Berechtigungen, die der Agent braucht.
Verbinden — MCP: die Serveradresse in Ihrer Werkbank hinterlegen. REST: den Schlüssel als Bearer-Token mitschicken.
Prüfen — Erster Aufruf: GET /v1/me bzw. list_vendors. Kommt eine Antwort, steht die Verbindung.

Schritt für Schritt in der Anwendung: Getting Started

Sie bauen einen eigenen Agenten?

Wir richten die Schlüssel ein und gehen den ersten Ablauf mit Ihnen durch.

Gespräch vereinbaren