For developers and architects
This page is for anyone who has to evaluate a platform before it comes in-house and wants to know how it is built: API, agent tooling, operations, failure behaviour.
At a glance
API
Rules, calculations, checks and follow-up actions apply through the API exactly as they do in the UI. There is no second, divergent route to the data.
OAuth 2.0 with client credentials. Access runs in the permission context of a defined user, so the same visibility rules apply as interactively.
Records and queries, plus triggering flows. The version is in the path, so a future incompatible version can live alongside the current one.
The API describes itself. Every installation ships interactive documentation for its own version, including the entities that exist in your system.
The points that regularly come up in a security review, and how they are handled here.
One runtime
There is no second route to the data
UI, REST API, AI tools, MCP and background processing go through the same translator and the same permission check. A forgotten check on the API is ruled out by design.
The central permission checkAgent tooling
nexxcite provides tools and uses tools from other systems, neither of which requires programming.
The platform offers tools that let an agent access your data: list entities, search and aggregate records, fetch related records, run saved queries.
External MCP servers can be configured; their tools become available to the assistant as well. Names are prefixed with the server name; unreachable servers are skipped and logged.
The stored access definition decides which protocol is spoken. Common providers and OpenAI-compatible endpoints are supported, as are open models in your own environment.
Operations
The platform is a .NET application with a SQL database, shipped as a container for Linux and Windows and run with Docker or Kubernetes. The UI is rendered on the server. Updates swap the container: configuration and data live in the database, not in the image.
Several instances behind a load balancer share the same database. The platform scales horizontally and vertically; clustering, high availability and geo-redundancy are possible.
Exactly one instance handles schedules and mailbox polling; otherwise every job would run several times. Background jobs run with monitoring.
The configuration cache is configurable in lifetime and behaviour; staggered expiry prevents everything reloading at once.
In the file system, Azure Blob Storage or S3-compatible storage, as you prefer.
Logs to file and standard output, ready for your log analysis. Plus a developer console, a data view and detection of unintended repetition while building the UI.
Spec sheet
| Topic | Detail |
|---|---|
| Runtime | .NET, UI rendered on the server |
| Data storage | Relational SQL database for configuration and business data |
| Delivery | Containers for Linux and Windows, Docker and Kubernetes |
| Operating models | SaaS, on-premises, private cloud |
| Scaling | Horizontal and vertical, clustered, highly available, geo-redundant possible |
| Sign-in | OpenID Connect, LDAP and Active Directory, two-factor authentication |
| API | REST, OAuth 2.0 client credentials, OpenAPI from the instance |
| Agents | MCP as server and as client |
| AI models | Your own API keys, common providers, OpenAI-compatible endpoints, open models in-house |
| Files and logs | File system, Azure Blob Storage, S3 · logs to file and standard output |
FAQ
For reading and reporting: yes, the schema is documented. For writing: strongly discouraged, because you would bypass exactly the rules and checks the shared runtime exists for.
Configuration is data and can be exported and imported. Within one environment, changes go through draft, approval and rollback. That is not a continuous release process across environments of the kind development platforms provide, though. In heavily regulated settings, this point should be discussed early.
OpenID Connect for single sign-on, LDAP and Active Directory for user and group data, two-factor authentication. Roles and permissions are managed in nexxcite; authentication can happen entirely outside.
The load balancer takes over. Sessions on the failed instance drop and are re-established; data is unaffected. For schedules, the designated instance applies.
Yes. The platform ships as a container and can be run with Docker or Kubernetes, with several instances behind a load balancer.
No hard product limits; the query layer pages results and uses indexes. Reliable figures depend on your sizing and are best worked out in a technical conversation.
The technical documentation for nexxcite is publicly available at docs.nexxcite.app. In addition, every installation ships the interactive description of its own API.
If you have specific technical questions, a session with our developers is usually quicker than a document.
Open the documentationTechnical session
Operating model, failure behaviour, data access, exit scenario. We would rather have a critical conversation before the project than a surprise during it.