Ressourcen
SwiftXEO bietet eine REST-API auf Workspace-Ebene, einen MCP-Server mit OAuth und signierte Inbound-Webhooks. Alle Schreiboperationen sind rein vorschlagend („propose-only“) – Freigaben bleiben angemeldeten Personen vorbehalten.
Verbinden Sie Claude, ChatGPT, Cursor oder eigene Systeme mit Ihrer freigegebenen Business-DNA, Ihren Zielen und aktiven Learnings. Reichen Sie Evidenz und Vorschläge über denselben menschlichen Review-Prozess ein wie alle anderen Inhalte.
Das Kernprinzip
Ein über API oder MCP angebundener Agent liest genau den freigegebenen Kontext, für den er autorisiert ist: Business-DNA, aktive Learnings, Ziele und Versionshistorie. Er kann prüfenswerte Punkte markieren und Learnings vorschlagen. Was er nicht kann: die Richtigkeit der eigenen Schlüsse selbst festlegen.
Kein API-Scope, kein Tool und kein Webhook kann ein Learning direkt freigeben oder aktivieren. Dies geschieht ausschließlich innerhalb von SwiftXEO durch eine autorisierte Person gemäß den geltenden Review-Regeln. Für die Aktivierung von Learnings ist zwingend ein Admin oder Workspace-Owner erforderlich.
Prinzipien der offenen Plattform
Anmeldedaten-gebundener Zugriff
Der Workspace wird aus dem Schlüssel abgeleitet. Er kann nicht durch einen Anfrage-Parameter ausgewählt oder überschrieben werden.
Freigegebenen Kontext lesen
Business-DNA, aktive Learnings, Ziele und Versionshistorie – exakt dieselbe Datenbasis, die auch dem Nutzer angezeigt wird.
Vorschlagen, niemals genehmigen
Externe Schreibzugriffe verbleiben im Status „Ausstehend“. Kein Scope erreicht die Autorisierungsroute.
Signierter Nachweis-Eingang
Webhook-Payloads werden per HMAC verifiziert und als verknüpfter Kontext zur Überprüfung gespeichert – niemals direkt ausgeführt.
Standardmäßig nicht vertrauenswürdig
Externes Material wird beim Eingang als nicht vertrauenswürdig markiert. Die Freigabe ist jedes Mal eine menschliche Entscheidung.
Projektierte Daten, keine Rohdaten
Antworten sind Positivlisten-Projektionen. Interne Kennungen bleiben intern; Prüfer erscheinen als Rollenbezeichnungen, nicht mit Namen.
Authentifizierung
Erstellen Sie unter Einstellungen → Infrastruktur → Zugriff auf offene Plattform einen Workspace-API-Schlüssel (Workspace-Admin erforderlich). Das Secret wird einmalig angezeigt; nur sein Hash wird gespeichert. Lese-Scopes sind ab dem Growth-Tarif enthalten; Schreib-Scopes erfordern den Execution-Tarif und werden bei der Verwendung erneut geprüft, sodass eine Tarifänderung sofort bei der nächsten Anfrage wirksam wird.
Authorization: Bearer sxk_live_k_xxxxxxxx_...
Business-DNA-Snapshot, aktive Learnings, Ziele und Versionshistorie
Workspace-Suche über Themen, Keywords, Kampagnen, Briefings und Wettbewerber
Learnings vorschlagen – landet immer mit Status PENDING in der menschlichen Review-Queue
Nachweise, Signale oder Dokumente als verknüpften Kontext einreichen
Geprüfte Content-Generierung – verbraucht Workspace-Credits
Growth = freigegebene Ausrichtung nutzen · Execution = zum kontrollierten Workflow beitragen
REST-API v1
Jede Antwort nutzt dasselbe Format – { data, meta? } bei Erfolg, { error: { code, message } } im Fehlerfall. Leseanfragen sind auf 60 Anfragen pro Minute pro Workspace beschränkt, Schreibanfragen auf 20. Die Generierung zieht vor dem Modellaufruf Workspace-Guthaben ab.
Freigegebener Business-DNA-Snapshot — zurückgegeben über eine begrenzte Allowlist-Projektion
Menschlich freigegebene (aktive) Learnings, filterbar nach Typ
Offene Wachstumsziele
Evidenz, Versionshistorie und menschliche Freigabedaten für eine Entität
Learning vorschlagen – verbleibt auf PENDING bis zur manuellen Freigabe
Verknüpften Kontext zur Überprüfung einreichen
Geprüfte Content-Generierung (Credit-basiert). Mit persist: true wird das Ergebnis als Entwurf mit Modell-/Task-Herkunft gespeichert; andernfalls wird nur der Text zurückgegeben
Für umfangreichere externe Aufgaben kann SwiftXEO zielgebundene Aufträge erteilen, die Ergebnisse entgegennehmen und spätere Beobachtungen direkt mit demselben Datensatz verknüpfen.
Erstellt eine abgegrenzte Kontextzuweisung für ein autorisiertes Ziel – der definierte Rahmen, auf dessen Basis ein externer Agent arbeitet
Ergebnisse zu einem Auftrag einreichen – Entwurf, Evidenz oder vorgeschlagenes Learning – verbleibt bis zum Review auf PENDING. Die Zuordnung wird serverseitig validiert; ungültige oder veraltete Auftrags-IDs werden abgewiesen
Eine qualitative oder metrische Beobachtung zu einem Zielergebnis melden – idempotent und vorbehaltlich menschlicher Überprüfung
curl https://www.swiftxeo.com/api/v1/context/dna \
-H "Authorization: Bearer sxk_live_k_xxxxxxxxxxxx_..."
curl -X POST https://www.swiftxeo.com/api/v1/learnings/propose \
-H "Authorization: Bearer sxk_live_k_xxxxxxxxxxxx_..." \
-H "Content-Type: application/json" \
-d '{
"kind": "content_learnings",
"category": "overclaim",
"lesson": "Avoid absolute performance claims without evidence.",
"evidenceNote": "Three campaign replies flagged the launch copy as overstated."
}'MCP-Server
Der Endpoint /api/mcp nutzt zustandsloses, streamfähiges HTTP. Zu den derzeit getesteten Hosted Clients gehören Claude (Web, Desktop, Mobil) und ChatGPT, die sich über OAuth verbinden: URL einfügen, anmelden, Workspace auswählen, Zugriff bestätigen. Konfigurationsdatei-Clients wie Claude Code und Cursor verwenden einen statischen Workspace-Key.
Die Tool-Liste wird nach den Scopes der Verbindung gefiltert: Lese-Tools liefern freigegebenen Kontext zurück, Schreib-Tools unterbreiten lediglich Vorschläge. Es gibt bewusst auf keiner Scope-Ebene ein Tool zum Genehmigen, Aktivieren oder Autorisieren.
Claude Code, Cursor & andere konfigurationsbasierte Clients
claude mcp add swiftxeo \ https://www.swiftxeo.com/api/mcp \ --transport http \ --header "Authorization: Bearer sxk_live_k_xxxxxxxxxxxx_..."
Claude Web, Desktop, Mobil & ChatGPT
Benutzerdefinierten Connector hinzufügen URL: https://www.swiftxeo.com/api/mcp → Bei SwiftXEO anmelden, Workspace auswählen, Zugriff bestätigen. Kein Schlüssel erforderlich – diese Verbindung nutzt OAuth.
Verfügbare Tools
Entwurfs-Updates bleiben reine Entwurfs-Mutationen. Eine externe Überarbeitung kann das Artefakt weder genehmigen, autorisieren, sperren noch veröffentlichen, und ein überarbeiteter Entwurf muss erneut überprüft werden, bevor er weiterverarbeitet werden kann.
Abgrenzung
Ein API-Schlüssel oder eine MCP/OAuth-Verbindung gewährt zielgerichteten Inbound-Zugriff auf die REST-API und die Tools von SwiftXEO – mehr nicht. Dadurch wird der Aufrufer nicht als Teammitglied im Agent Room registriert und erhält niemals Sichtbarkeit für @mentions innerhalb des Agent Rooms eines Workspaces.
Die Teampartner im Agent Room bilden ein festes Set: Claude, OpenAI, Gemini, der SwiftXEO Advisor und der Verifier. Jeder verfügt über eigene Routing- und Zugriffsregeln, die durch externe Zugangsdaten weder erweitert noch umgangen werden können.
Das Local-Connector-Protokoll ist eine separate Schnittstelle. Es koppelt eine lokale Runtime (z. B. einen Mac für Agent-Room-Aufgaben) mit eigenen Zugangsdaten, Leases und Widerrufsmechanismen – unabhängig von API-Keys und MCP-Verbindungen.
Eingehende Webhooks
Erstellen Sie eine Inbound-Quelle unter Einstellungen → Infrastruktur → Inbound-Quellen, um einen quellenspezifischen Endpoint und ein Signing Secret zu erhalten. Jede Payload wird mit HMAC-SHA256 über den Raw Body verifiziert, bevor sie als verknüpfter Kontext eingeht — Material für die menschliche Überprüfung, niemals eine eigenständige Wahrheit. Schlägt die Verifizierung fehl, wird die Anfrage abgelehnt, bevor etwas geparst oder gespeichert wird.
Growth enthält eine aktive Quelle; Execution ermöglicht mehrere.
POST /api/hooks/{workspaceId}/{sourceId}
X-Signature: sha256=<hmac of raw body>
{
"kind": "signal",
"title": "CRM: deal closed",
"body": "Acme signed the annual
plan after the Q3 campaign."
}Fragen
Nein. Kein API-Scope, MCP-Tool oder Webhook kann Vorschläge als genehmigt markieren oder die Freigaberoute aufrufen. Externe Systeme können freigegebenen Kontext lesen, Evidenz beisteuern und Learnings vorschlagen. Jeder Vorschlag landet im Status „Pending“. Das Aktivieren erfordert einen angemeldeten Admin oder Workspace-Owner.
Über zwei Anmeldedaten-Typen auf demselben Bearer-Header: ein statischer Workspace-API-Schlüssel für konfigurationsbasierte Clients oder ein OAuth-Access-Token für gehostete Clients wie Claude und ChatGPT. In beiden Fällen stammt der Workspace aus den Anmeldedaten – niemals aus Tool-Argumenten.
Der Growth-Tarif umfasst Lesezugriffe: Business-DNA, Ziele, aktive Learnings, Versionshistorie, Workspace-Suche und eine Inbound-Webhook-Quelle. Execution ergänzt Schreibzugriffe: Vorschlagen von Learnings, Einreichen von Evidenz, geprüfte Content-Generierung und mehrere Inbound-Quellen.
Ausschließlich Rollenbezeichnungen. Externe Antworten werden über eine Anonymisierungsschicht projiziert: Die Identitäten von Prüfern und Autoren werden zu „Workspace-Administrator“, und interne Kennungen werden entfernt, bevor etwas den Workspace verlässt.
Die vollständige Plattform-Referenz finden Sie in unserer Dokumentation. Die Seite zur Open Platform erläutert das Review-Modell hinter diesen Endpunkten.