Licensed to be used in conjunction with basebox, only.
// integration
Business systems
Applies to
Product: Cloud · Server · Audience: Administrator · IT · Developer / Integrator
Connecting wikis, ticket systems, file stores, hospital or ERP systems via connectors – what is available, how to request more or build your own, and which properties a system should have so the connection works cleanly.
What a connector does
A connector gives the assistant tools: search, read, list – and, if explicitly enabled, change. Users ask in the chat as usual; the assistant recognises that the answer lies in the business system, calls the tool with the asking person's credentials and answers with what that person may see there. Technically, connectors are MCP servers – see MCP overview.
Available connections
| System | Connector | Access model | Setup |
|---|---|---|---|
| DokuWiki (self-hosted) | DokuWiki | Personal: username/password or token | Platform Operator sets XML-RPC URL via Helm (Server); administrator enables. Details |
| YouTrack (JetBrains) | YouTrack | Personal: permanent token | Connector hosted by JetBrains, no cluster workload. Details · Create token |
| Jira / Confluence (Atlassian) | Atlassian | Personal | Per project with basebox support; base URLs via Helm |
| Nextcloud | Nextcloud | Personal | Per project with basebox support; base URL via Helm |
| E-mail mailbox (IMAP) | Personal: mailbox login | IMAP host/port/connection type via Helm; each user enters their own credentials | |
| roXtra (quality management) | roXtra, planned | Personal: API token | Not yet available to customers; access to the interface is being clarified |
| Public web | Web search | No user login; optional organisation API key | Web search |
Calculator, web search and e-mail form the standard profile; the others are set up per project. How deployment works: Deploying MCP connectors with Helm · Configuring connectors.
Connecting another system
Three paths, depending on what the system offers:
- Request to basebox. If you need a connector missing above, contact support@basebox.ai. Name the system, its API and the desired access model.
- Existing MCP server from the vendor. If the vendor of your system already offers an MCP server (as JetBrains does for YouTrack), it can be connected as a hosted endpoint – see Connect an MCP server.
- Build it yourself. For internal systems with their own API, develop your own connector following the basebox rules – see Build connectors – and have the Platform Operator deploy it.
What a system should provide
Not every business system can be connected equally well. Check in advance:
| Property | Why it matters |
|---|---|
| API with per-user authentication (personal tokens, OAuth) | Enables the "personal credentials" access model – the system enforces its own permissions |
| Search and targeted retrieval (not just full lists) | The assistant needs tools that return small, relevant results |
| Stable identifiers and links | So answers can point to the original document |
| Network reachability from basebox | Firewall rule from basebox to the system; in the Cloud from basebox's data centre (noris network, Munich) |
| Separation of read and write operations | Writing stays off by default and is enabled deliberately |
Systems that offer only a shared service account can be connected – but then all users see the same. That is acceptable only for generally accessible content.
Hospital and administrative systems
For systems with particularly sensitive data – patient records, HR, finance – the following applies in addition:
- Access to the hospital information system is provided by its vendor, for example via FHIR according to ISiK or an existing interface of the hospital. Only then does basebox build the connector.
- FHIR does not mean connected. The basebox FHIR connector (FHIR R4) is built on the gematik ISiK specification and adapted per system. What it can read depends on which ISiK stage and modules the vendor has implemented and what the hospital releases.
-
HL7 v2 through the communication server. HL7 v2 messages report events (admission, finding) and are not suited for targeted queries. basebox does not listen in on them; it queries through an interface the communication server provides, for example FHIR.
-
Personal credentials are mandatory. Only then does the attribution "who saw what" stay consistent in the source system and in the basebox audit log.
- A dedicated app per system. Keep the connector for a sensitive system in its own app, without web search – so the path "internal data → web search" does not exist. Background: Introduction to web search security.
- Results are data. basebox frames everything that comes from a connector as data, not as instructions, and checks for manipulation such as hidden instructions in content. Complete protection is not possible; that is why permissions, read-only access and approval by a person come on top.
- What the audit log records: organisation, user, tool, target, result, timestamp – not the content. See Audit & logging.
- Include a data protection impact assessment when personal data is processed via the assistant – see GDPR.
Roles in connecting a system
| Step | Who |
|---|---|
| Select the system, decide the access model | Administrator with business unit and data protection |
| Set endpoints via Helm, deploy the workload, firewall | Platform Operator (Server) / basebox (Cloud) |
| Configure and test the connector, enable for apps | Administrator |
| Generate and enter personal tokens | Each user themselves |
| Develop a custom connector | Developer / Integrator |
Next step: Connector authentication · Connector permissions · Available connectors (user view)