# API and integrations: build automations with coreAI, or build coreAI into your product

coreAI isn't a closed chatbot – it's a platform with open interfaces you can build automations around or build straight into your own products. The entity everything hangs on is the **knowledge base**: it holds the sources and the data, and on top of it you build one or more **assistants** that are the responding surfaces toward your users. Whether you want to fill a knowledge base with data from your own system, let it perform actions in your line-of-business systems, or let other AI agents fetch answers from it, the same building blocks apply: a REST API for data and conversation, and the Model Context Protocol (MCP) for letting AI talk to tools and systems. Everything hangs on the same knowledge base, the same sources, and the access controls you already have.

![Sketch of the three integration patterns in coreAI: send data in via the REST API, build coreAI into your own surfaces, and let AI read and act via MCP – all against the same knowledge base](/articles/en/api-integration-patterns.svg)

## Three ways to integrate

Broadly there are three integration patterns, and they can be combined in the same product:

- **Send data in.** You push structured data from your own system into the knowledge base via the REST API. There it is converted automatically into coreAI's internal format – a representation format optimised for AI understanding, not for storage in a database. Your fields are mapped to semantic entities, the text is normalised and enriched, and the content is indexed so the model finds and understands it quickly. You send your raw data as it is; coreAI does the heavy lifting of turning it into solid answer material for chat and search.
- **Build coreAI in.** You call the chat and search endpoints directly and build the experience into your own surfaces – your own UI, your own session handling, your own model and prompt configuration.
- **Let AI read and act.** You connect the knowledge base to your MCP servers so the assistants can fetch fresh data and perform actions through tool calling – or expose coreAI as an MCP server other agents connect to.

## The REST API: fill the knowledge base and build your own surfaces

The REST API is the entry point for systems that want to send their own data directly into a knowledge base and use it in chat or search. All calls to API v2 go to `https://portal.coreai.no/api/v2` (or the stage environment in test), authenticate with a Bearer token, and the most important paths need both `assistantId` (the assistant that responds – a knowledge base can have one or more) and `contentImporterId` (the source the data is stored in).

The main flow is **upsert**: your system sends a `POST` every time an object is created or changed, and coreAI creates or updates the entity on a stable external ID. `PATCH` sends only the fields that changed, and `DELETE` removes entities that should no longer produce answers. The entity types cover the most common data sources – `products`, `contents`, `documents`, `events`, `contacts`, `job_postings`, and `educations` – and custom `properties` make the content filterable in later chat and search calls. The full recipe, with field requirements and filter operators, is in [how to fill a knowledge base with data via the API](https://coreai.no/en/articles/api-data-integration).

If you want to build the experience yourself, you call `/assistants/{assistantId}/chat` with the question and optional parameters such as `cid`, `lang`, `model`, `sources`, `filters`, and `stream`, or `/assistants/{assistantId}/search` when you only need hits and facets without a generated answer. Chat streams are published over WebSocket, so you can build a responsive, streaming experience in your own interface. The simplest route is still the coreAI widget, which handles conversation ID, language, and streaming for you – the API is there when you need full control.

## MCP and tool calling: let the knowledge base read and act in other systems

Where the REST API fills the knowledge base with relatively stable data, MCP is built for what has to be live or requires an action. The Model Context Protocol is the open standard that lets AI models talk to external data sources and tools without vendor-specific SDKs, and coreAI implements it both ways.

As an **MCP client**, the knowledge base connects to the MCP servers you already have, reads which tools they offer, and the assistants pick the right tool per question through tool calling. The tools can both read and write: fetch live stock levels and order data, or create a case, reschedule a delivery, and cancel a subscription. This is what makes the assistant agentic – it completes tasks, it doesn't just answer. Your line-of-business system still decides what a given tool is allowed to do, and for logged-in users a user token can be forwarded to the MCP server as `X-User-Token` so the answer is scoped to the user's own data. See [coreAI as MCP client and MCP server](https://coreai.no/en/articles/mcp) for the full picture, and [the MCP import as a client integration](https://coreai.no/en/articles/mcp-import) for how tool schemas are fetched and selected in real time. How this ties into building actions into your business processes is covered in [the agentic AI solution](https://coreai.no/en/solutions/agentic-ai).

As an **MCP server**, coreAI exposes the knowledge base over standard MCP transport, so external AI agents – Claude Desktop, Cursor, ChatGPT, internal dev agents, or orchestration platforms – can look up the same curated source the chat uses. No copying, no separate vector index, no scraping. Access is three-layered: each token belongs to a user or system account, each call points to one assistant, and each assistant is bound to the sources in its knowledge base. The details are in [MCP server as a shared retrieval layer](https://coreai.no/en/articles/mcp-server).

## One knowledge base, many surfaces

The strength of the architecture is that everything hangs on the same knowledge base and the same sources. A product can offer the chat widget to end users, build the search API into its own admin panel, push data via the REST API, and let its own AI agents connect via MCP – at the same time. Change a source text in coreAI and the change lands on every surface in the same instant, without you maintaining three separate data synchronisations.

The rule of thumb is simple: anything that can stay stable for hours or days belongs in the knowledge base via the REST API; anything that requires a live lookup or an action against another system belongs behind MCP. That gives you a knowledge base with fresh data, traceable sources, and an interface you can build as simply or as specialised as your product requires.

## How to get started

Start by choosing the integration pattern that solves your task: send data in with the REST API, build chat and search into your own surfaces, or connect MCP for live data and actions. You fetch the token, assistant ID, and source ID in the coreAI portal on the relevant knowledge base, and the MCP configuration can be copied straight from the "Code" tab. [Get in touch for a walkthrough](https://coreai.no/en/contact) of how the APIs fit your exact architecture.