How Syncanix works
From one discovery command to a live assistant: how the capability catalog connects the CLI, the widget, the chat surface, and the MCP server.
Syncanix is built around one idea: discover what your product can do once, then reuse it everywhere. That discovery produces a capability catalog, and everything else is a view onto it.
1. Discover your API
Run the CLI in your project. It detects your framework, reads your routes, and extracts a catalog of capabilities. Discovery is static by default — it reads your code; it does not run it, and no production data leaves your machine.
npx syncanix initOptional AI enrichment (clearer titles and descriptions) only runs after you give explicit zero-data-retention consent. The CLI will not send anything otherwise.
2. Embed the widget
Add one script tag to your app. The widget loads lazily, runs inside a Shadow DOM so your styles and ours never collide, and picks up your brand from your existing design system automatically.
<script
type="module"
src="https://cdn.syncanix.com/widget.js"
data-key="pk_live_..."
></script>3. Chat that takes action
The assistant answers questions and runs your API actions as the signed-in user — using their identity from your identity provider, never a shared credential. Actions are gated by how risky they are:
- Read actions (look something up) can run automatically.
- Write actions (change something) ask the user to confirm first.
- Destructive actions are blocked by default until you explicitly allow them, and can require a re-authentication step.
4. Connect AI clients over MCP
Each workspace gets its own MCP server, so your users can reach the same capabilities from Claude Desktop, Cursor, ChatGPT, and other MCP-capable clients. Sign-in federates to your identity provider, so the same identity and permissions apply there too.
Configure everything in the dashboard
The dashboard is where you review the catalog, set each action’s risk level and permissions, write the assistant’s persona, connect knowledge sources, design the widget, manage your team, and watch usage and costs. Changes are made in a development environment first, then promoted to production.
The journey at a glance
A typical first run, from an existing app to a live assistant:
- DiscoverRun the CLI to scan your API and upload the capability catalog.
- Review & configureIn the dashboard, set risk levels, permissions, and the assistant’s persona.
- EmbedAdd the widget script to your app and confirm it matches your brand.
- PromotePromote from development to production when you’re happy with how it behaves.