# API und Integrationen: bauen Sie Automatisierungen mit coreAI oder bauen Sie coreAI in Ihr Produkt ein

coreAI ist kein geschlossener Chatbot – es ist eine Plattform mit offenen Schnittstellen, um die Sie Automatisierungen bauen oder die Sie direkt in Ihre eigenen Produkte einbauen können. Die Einheit, an der alles hängt, ist die **Wissensbasis**: Sie hält die Quellen und die Daten, und auf ihr bauen Sie einen oder mehrere **Assistenten** auf, die die antwortenden Oberflächen gegenüber Ihren Nutzern sind. Ob Sie eine Wissensbasis mit Daten aus Ihrem eigenen System befüllen, sie Aktionen in Ihren Fachsystemen ausführen lassen oder andere KI-Agenten Antworten aus ihr holen lassen wollen: Es gelten dieselben Bausteine – eine REST-API für Daten und Konversation und das Model Context Protocol (MCP), damit KI mit Werkzeugen und Systemen sprechen kann. Alles hängt an derselben Wissensbasis, denselben Quellen und der Zugriffssteuerung, die Sie bereits haben.

![Skizze der drei Integrationsmuster in coreAI: Daten über die REST-API senden, coreAI in eigene Oberflächen einbauen und KI über MCP lesen und handeln lassen – alle gegen dieselbe Wissensbasis](/articles/de/api-integration-patterns.svg)

## Drei Wege zu integrieren

Grob gesagt gibt es drei Integrationsmuster, und sie lassen sich im selben Produkt kombinieren:

- **Daten hineinsenden.** Sie pushen strukturierte Daten aus Ihrem eigenen System über die REST-API in die Wissensbasis. Dort werden sie automatisch in das interne Format von coreAI konvertiert – ein Repräsentationsformat, das für das KI-Verständnis optimiert ist, nicht für die Speicherung in einer Datenbank. Ihre Felder werden auf semantische Einheiten abgebildet, der Text wird normalisiert und angereichert, und der Inhalt wird indexiert, damit das Modell ihn schnell findet und versteht. Sie senden also Ihre Rohdaten so, wie sie sind; coreAI übernimmt die Schwerstarbeit, daraus gutes Antwortmaterial für Chat und Suche zu machen.
- **coreAI einbauen.** Sie rufen die Chat- und Such-Endpunkte direkt auf und bauen das Erlebnis in Ihre eigenen Oberflächen ein – eigene UI, eigene Sitzungsverwaltung, eigene Modell- und Prompt-Konfiguration.
- **KI lesen und handeln lassen.** Sie binden die Wissensbasis an Ihre MCP-Server an, damit die Assistenten über Tool Calling frische Daten holen und Aktionen ausführen können – oder Sie stellen coreAI als MCP-Server bereit, mit dem sich andere Agenten verbinden.

## Die REST-API: Wissensbasis befüllen und eigene Oberflächen bauen

Die REST-API ist der Einstieg für Systeme, die ihre eigenen Daten direkt in eine Wissensbasis senden und in Chat oder Suche verwenden wollen. Alle Aufrufe an API v2 gehen an `https://portal.coreai.no/api/v2` (oder die Stage-Umgebung im Test), werden mit einem Bearer-Token authentifiziert, und die wichtigsten Pfade benötigen sowohl `assistantId` (der antwortende Assistent – eine Wissensbasis kann einen oder mehrere haben) als auch `contentImporterId` (die Quelle, in der die Daten gespeichert werden).

Der Hauptablauf ist **Upsert**: Ihr System sendet jedes Mal einen `POST`, wenn ein Objekt erstellt oder geändert wird, und coreAI erstellt oder aktualisiert die Entität anhand einer stabilen externen ID. `PATCH` sendet nur die geänderten Felder, und `DELETE` entfernt Entitäten, die keine Antworten mehr liefern sollen. Die Entitätstypen decken die häufigsten Datenquellen ab – `products`, `contents`, `documents`, `events`, `contacts`, `job_postings` und `educations` – und benutzerdefinierte `properties` machen den Inhalt in späteren Chat- und Suchaufrufen filterbar. Das vollständige Rezept mit Feldanforderungen und Filteroperatoren finden Sie in [so befüllen Sie eine Wissensbasis über die API mit Daten](https://coreai.no/de/articles/api-data-integration).

Wenn Sie das Erlebnis selbst bauen wollen, rufen Sie `/assistants/{assistantId}/chat` mit der Frage und optionalen Parametern wie `cid`, `lang`, `model`, `sources`, `filters` und `stream` auf, oder `/assistants/{assistantId}/search`, wenn Sie nur Treffer und Facetten ohne generierte Antwort benötigen. Chat-Streams werden über WebSocket veröffentlicht, sodass Sie ein responsives, streamendes Erlebnis in Ihrer eigenen Oberfläche bauen können. Der einfachste Weg ist nach wie vor das coreAI-Widget, das Konversations-ID, Sprache und Streaming für Sie übernimmt – die API ist da, wenn Sie volle Kontrolle brauchen.

## MCP und Tool Calling: die Wissensbasis in anderen Systemen lesen und handeln lassen

Wo die REST-API die Wissensbasis mit relativ stabilen Daten befüllt, ist MCP für das gebaut, was live sein muss oder eine Aktion erfordert. Das Model Context Protocol ist der offene Standard, der KI-Modellen erlaubt, ohne anbieterspezifische SDKs mit externen Datenquellen und Werkzeugen zu sprechen, und coreAI implementiert es in beide Richtungen.

Als **MCP-Client** verbindet sich die Wissensbasis mit den MCP-Servern, die Sie bereits haben, liest aus, welche Werkzeuge sie anbieten, und die Assistenten wählen pro Frage über Tool Calling das richtige Werkzeug. Die Werkzeuge können sowohl lesen als auch schreiben: Live-Lagerstände und Auftragsdaten abrufen, oder einen Vorgang anlegen, eine Lieferung verschieben und ein Abonnement kündigen. Genau das macht den Assistenten agentisch – er erledigt Aufgaben, er antwortet nicht nur. Ihr Fachsystem entscheidet weiterhin, was ein bestimmtes Werkzeug tun darf, und für angemeldete Nutzer kann ein Benutzertoken als `X-User-Token` an den MCP-Server weitergereicht werden, sodass die Antwort auf die eigenen Daten des Nutzers begrenzt wird. Das vollständige Bild finden Sie in [coreAI als MCP-Client und MCP-Server](https://coreai.no/de/articles/mcp), und wie Werkzeugschemata in Echtzeit abgerufen und ausgewählt werden, in [der MCP-Import als Client-Integration](https://coreai.no/de/articles/mcp-import). Wie das mit dem Einbau von Aktionen in Ihre Geschäftsprozesse zusammenhängt, steht in [der agentischen KI-Lösung](https://coreai.no/de/solutions/agentic-ai).

Als **MCP-Server** stellt coreAI die Wissensbasis über den Standard-MCP-Transport bereit, sodass externe KI-Agenten – Claude Desktop, Cursor, ChatGPT, interne Dev-Agenten oder Orchestrierungsplattformen – dieselbe kuratierte Quelle nachschlagen können, die auch der Chat nutzt. Kein Kopieren, kein separater Vektorindex, kein Scraping. Der Zugriff ist dreischichtig: Jedes Token gehört zu einem Nutzer- oder Systemkonto, jeder Aufruf zeigt auf einen Assistenten, und jeder Assistent ist an die Quellen in seiner Wissensbasis gebunden. Die Details stehen in [MCP-Server als gemeinsame Retrieval-Ebene](https://coreai.no/de/articles/mcp-server).

## Eine Wissensbasis, viele Oberflächen

Die Stärke der Architektur ist, dass alles an derselben Wissensbasis und denselben Quellen hängt. Ein Produkt kann das Chat-Widget für Endnutzer anbieten, die Such-API in sein eigenes Admin-Panel einbauen, Daten über die REST-API pushen und eigene KI-Agenten über MCP anbinden – gleichzeitig. Ändern Sie einen Quelltext in coreAI, schlägt die Änderung im selben Moment auf allen Oberflächen durch, ohne dass Sie drei separate Datensynchronisierungen pflegen.

Die Faustregel ist einfach: Alles, was Stunden oder Tage stabil bleiben kann, gehört über die REST-API in die Wissensbasis; alles, was eine Live-Abfrage oder eine Aktion gegen ein anderes System erfordert, gehört hinter MCP. So erhalten Sie eine Wissensbasis mit frischen Daten, nachvollziehbaren Quellen und eine Schnittstelle, die Sie so einfach oder so spezialisiert bauen können, wie Ihr Produkt es verlangt.

## So legen Sie los

Beginnen Sie damit, das Integrationsmuster zu wählen, das Ihre Aufgabe löst: Daten mit der REST-API hineinsenden, Chat und Suche in eigene Oberflächen einbauen oder MCP für Live-Daten und Aktionen anbinden. Token, Assistenten-ID und Quell-ID holen Sie im coreAI-Portal an der jeweiligen Wissensbasis, und die MCP-Konfiguration können Sie direkt aus dem Reiter „Code" kopieren. [Nehmen Sie Kontakt auf für eine Durchsprache](https://coreai.no/de/kontakt), wie die APIs zu Ihrer konkreten Architektur passen.