Architecture overview
How Syncanix connects your users, your API, and the AI — and where it all runs.
This page is a high-level map of how Syncanix fits together: what happens when a user asks the assistant for something, how their identity is used, and where your data lives. You don’t need any of this to get started, but it helps to understand the shape of the system.
How a request flows
Whether a request comes from the embedded widget or an MCP client, the same path runs:
- The user asksA signed-in user types a request in the widget, or sends one from an MCP client like Claude Desktop.
- Syncanix plansThe assistant matches the request against your capability catalog and decides which of your API actions, if any, would answer it — pausing for confirmation when an action changes data.
- Your API actsApproved actions run against your own API as that user, using their identity from your identity provider. The result returns to the conversation, and the call is recorded in the audit trail.
Your users' credentials never reach the AI
The assistant works from a structured description of what your API can do — not from your users' passwords or session tokens. Each action runs under the end user’s own identity, supplied by your identity provider at the moment it is needed. The language model sees the request and the catalog; it never holds a credential it could misuse.
Reliable by design
Syncanix routes to more than one AI provider (Anthropic and OpenAI, plus AWS Bedrock in the EU) and fails over automatically if one is unavailable, so a single provider’s outage doesn’t take your assistant down. You can also bring your own provider keys.
Where it runs
Syncanix’s infrastructure runs entirely in the European Union — on AWS in Frankfurt (eu-central-1) — with your data encrypted at rest. Chat replies are generated transiently by the model provider under its API terms (excluded from training; ZDR agreements being finalized); retrieval embeddings and reranking stay in-region on Amazon Bedrock.
Your data stays yours
Every workspace is isolated from every other. A request is always scoped to the workspace it belongs to — across the database, caches, logs, and stored files — so one customer can never see another’s data.
Develop, then promote
Each workspace has two environments: a development environment to set things up and try them safely, and a production environment your users reach. You make changes in development and promote them to production when you are ready, so live behaviour only ever changes on purpose.