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.
Side effect: What an action does to your data: read (looks something up), write (changes something), or destructive (deletes or irreversibly changes). The side effect sets how the action is confirmed.
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.
Grounding (retrieval): Answering from your own documentation and content rather than the model's general knowledge. The assistant retrieves relevant material and cites it, so answers reflect your product.
Approved websites: The pages and domains the agent may READ while it answers — outbound, and read-only. Without an entry it reads nothing outside your own catalog, connectors and indexed documentation. Not the same thing as widget origins, which govern the opposite direction: which of your sites may EMBED the widget. Each entry is approved by an admin, restricted to GET, re-checked against your rules on every request and on every redirect hop, and can never point at a private or internal address.
Site mapping: Syncanix learning your product by reading it. Your own pages open in your browser, signed in as you, and Syncanix records what each one holds — the sections, the forms, the buttons, and the paths between them — so the agent can answer about your product and walk people through it. Not your sitemap, which is the list of addresses your site publishes for search engines: mapping is about what is on a page, not which pages exist. Not the Interaction Map either, which charts what end users did once the agent was live.
Site manual: A generated, structured description of your site — its pages, controls and flows — assembled from discovery for workspaces with no docs of their own. The agent grounds site questions in it and cites it like any other source, in the visitor’s language.
Task guides: A named, published flow the agent can walk a visitor through on your own pages — the steps themselves, pointed out one control at a time, not an article describing them. Syncanix proposes guides from what discovery observed and from flows you demonstrate; none is offered to anyone until you publish it.
Engagement: The one place your assistant's outreach is configured: what it offers a visitor before they type (suggestions), when it speaks first (nudges), and where it appears at all (page rules). Not a metrics page — every analytics surface in the product measures engagement, and this is where the behavior itself is set. It replaces three separate pages that each described one part of the same visitor experience.
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 embed the widget, 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.
User Learning: An opt-in capability that lets the assistant learn durable preferences and context about each signed-in end user from their conversations, injecting a compact, budget-capped summary into future turns to personalize responses and available actions.
Agent Impact: The analytics surface that measures the business value the agent delivers — how many end-user requests it resolved without human help (deflection), the outcomes of those conversations, and an estimated return on investment — aggregated nightly per workspace with honest sampling disclosure.
Interaction: One charged turn — a question and the assistant's answer, including any tool, MCP, or endpoint calls that answer makes — or one standalone tool call. Each has a posted price: 3 usage credits to answer, 6 if it also took an action, 9 if it also looked something up, 12 if it did both. A conversation is several interactions, not one. Unrelated to the Interaction Map, which visualizes journeys rather than pricing them.
Interaction Map: A visual map of the agent's capability graph and the journeys end users take through it — which areas, routes, and capabilities they reach, where demand concentrates, and where capability gaps remain — rendered as an interactive canvas with an accessible table view. It carries no prices: the unit that does is the interaction.
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.
JSON Web Token (JWT): A compact, signed token that proves who a signed-in user is. Your identity provider issues it; Syncanix verifies its signature to trust the identity.
JWKS (JSON Web Key Set): The set of public keys your identity provider publishes so services can verify the signatures on its tokens, without ever sharing a secret.
OpenID Connect (OIDC): The standard sign-in protocol most identity providers speak. If yours supports it, Syncanix can verify your users through it.
PKCE (Proof Key for Code Exchange): A security step in the OAuth sign-in flow that stops an intercepted authorization code from being used by anyone else. MCP clients sign in this way.
Scope: A named permission attached to a token — what the holder is allowed to do. The assistant's actions are bounded by the user's scopes, never more.
Token exchange: A standard (RFC 8693) way to swap one token for a narrower one bound to a specific job — used in enterprise setups so every downstream action gets its own explicitly-issued, scoped token.
Backend-for-frontend (BFF): A small server you run that sits between the widget and Syncanix, so authentication tokens never reach the browser. The most locked-down way to authenticate your users.
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.
Row-level security: A database feature that filters every query to one workspace's rows automatically — Syncanix's final backstop keeping customers' data apart even if a query forgets to scope itself.
Signed intent: A tamper-proof, single-use token that binds an approved action to a specific user, capability, and inputs, so a confirmed action can't be altered or replayed.
Evaluation gate: An automatic quality check that runs before you promote to production and blocks the change if the assistant's answers regress — so production only ever changes for the better.
Drift detection: Noticing when your API or its behavior changes so the catalog no longer matches reality, and flagging it so the assistant never acts on a stale picture.
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 by your provider rather than counting against your plan.
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.
UC (usage credits): The unit Syncanix prices interactions in. Every interaction costs 6, 15, 18, or 30 UC, set by what it did — answering, acting, looking something up, or both. Plans are sized by included usage credits, so usage (not headcount) drives cost.
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 behavior 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.