Glossary

Key terms used across the Syncanix documentation.

The cross-cutting vocabulary used throughout these docs. Later sections define their own domain terms where they appear.

Capability: A single thing your API can do — one endpoint or action, like “refund an order” — described so the assistant knows what it does and when to use it.
Capability catalog: The structured list of all your capabilities. It is discovered from your API and is the single source of truth the widget, chat, and MCP server all read from.
Discovery: The process of scanning your codebase to build the capability catalog, run by the Syncanix CLI.
Widget: The embeddable chat component you add to your app with a single script tag.
Chat surface: The assistant experience your users interact with — answering questions and taking actions through your API.
MCP (Model Context Protocol): An open standard that lets AI clients such as Claude Desktop, Cursor, and ChatGPT connect to external tools and data.
MCP server: The per-workspace endpoint Syncanix gives you so MCP clients can reach your capabilities.
Builder / admin: Your team — the people who run the CLI, configure the dashboard, and manage the workspace.
End user: Your customer’s signed-in user, who chats with the widget or connects an MCP client. Their own identity — not a shared one — is used for every action.
Identity provider (IdP): The service that authenticates your users — for example Auth0, Clerk, Cognito, or WorkOS. Syncanix uses it instead of storing credentials itself.
Federation: Delegating sign-in to your identity provider, so the same login and permissions your users already have apply inside Syncanix.
Step-up authentication: Asking a user to re-confirm their identity — for example with multi-factor authentication — before a sensitive action runs.
Act on behalf: The assistant performing an action as the end user, with their identity and permissions — never with elevated or shared access.
Confirmation tiers: How Syncanix gates actions by risk: read actions can run automatically, write actions ask for confirmation, and destructive actions are blocked unless you allow them.
Zero data retention (ZDR): An arrangement where an AI provider processes a request without storing it or training on it. The CLI requires your explicit consent before any AI enrichment.
BYOK (bring your own key): Using your own AI provider keys, so model usage is billed directly to you with no Syncanix markup.
BYOMCP (bring your own MCP server): Connecting MCP servers you already run as extra tool sources. Their tools appear alongside your discovered catalog, and calls are forwarded to your server with tenant isolation and step-up authentication honored.
Witness: A runtime observation of an API call's shape — field names and inferred types, never values — produced by the opt-in api-witness middleware. Witnesses keep the catalog aligned with what your API actually serves.
MAEU (monthly active end users): The number of distinct end users who interact with your assistant in a month — the primary measure plans are sized by.
Environment: An isolated copy of your configuration. Each workspace has a development environment for setup and a production environment your users reach.
Promote: Moving your configuration from development to production, so live behaviour only changes when you intend it to.
Publishable & secret keys: A publishable key (pk_…) is safe to embed in your web page for the widget; a secret key (gak_…) is used server-side, for example by the CLI. Never expose a secret key in client code.
Workspace: A single Syncanix tenant — your project, with its catalog, configuration, team, and billing. You can belong to more than one.