Glossario

The words these docs use, defined once. Each entry gives the plain phrase first and the technical name in parentheses, then links to the guide that uses it. Generic standards get one line and a link to the specification. Every developer page follows the same convention at the first mention of a term.

Workspace (tenant)

Your own space on the platform, kept separate from everyone else's: name, slug, branding, web addresses, sign-in provider, connections, content, model rules and limits. Everything your customers do stays inside it. In the API and tool names it is called a tenant.

See: Getting started

Your address on our domain (default host)

The <slug>.busymate.ai address every workspace answers at from the moment it exists, before any DNS work.

See: Serve your assistant on your own domain

Your own domain (white-label host)

Your own web address, mapped to your workspace after you prove you own it (a TXT record) and point it at us (a CNAME). Your customers see your domain only.

See: Serve your assistant on your own domain

Signed-in customer (identified launch)

Opening the assistant as a known customer: the widget or app hands over a proof your product signed, and bro serves that customer's history and account tools.

See: Recognize signed-in customers

Sign-in proof (launch token)

A short-lived signed proof (a JWT, ES256 by default, at most 120 seconds) your API creates for one signed-in customer: issuer, audience busymate-ai, workspace claim, unchanging subject, nonce, one-time jti.

See: Recognize signed-in customers

One-time values (nonce and jti)

The two values on a sign-in proof that can be used once. The widget generates the nonce and your endpoint echoes it; the jti is the proof's own id. Each pair is consumed exactly once, so a replay is refused.

See: Recognize signed-in customers

Your sign-in provider (identity provider)

What the platform checks sign-in proofs against: your issuer, public-key URL (JWKS), audience, workspace and subject claims, allowed algorithms, maximum proof age and the endpoint that creates proofs.

See: Recognize signed-in customers

Access levels (tool tiers)

The three levels a tool can have: open to anyone (public — non-personal look-ups), signed-in customers (identified — their own data), on the customer's behalf (delegated — for changes you want explicitly authorized).

See: Connect your MCP server as assistant tools

Confirmation step (confirm gate)

The per-tool flag that stops a change at a card showing the exact action; it runs only after the customer says yes. Not a fourth level — a step on any level's tool.

See: Connect your MCP server as assistant tools

Action proof (signed actor token)

The pass bro sends your MCP server when your product already verified the visitor: signed by the platform, valid at most five minutes, issuer https://busymate.ai, audience your origin, workspace and connection pinned. No second consent prompt.

See: Connect your MCP server as assistant tools

Each customer connects their own account (per-user OAuth)

The alternative: each customer authorizes their own account with your authorization server through OAuth 2.1 with PKCE. Use it when a separate consent screen is intentional.

See: Connect your MCP server as assistant tools

Connection (connector)

A registered MCP server on your workspace: address, transport, how it authenticates, how it learns who the customer is, and the access level and confirmation flag of every tool it exposes.

See: Connect your MCP server as assistant tools

Published version (revision)

One frozen, published set of your settings. Draft, then checks (preflight), then publish, then live. A failed check leaves the draft a draft. "Live" (projection) is the copy the assistant serves; published and live are reported separately.

See: Getting started

Handoff (intervention)

A conversation moving from the assistant to your team, with the whole chat attached. Raised when a customer asks for a person, when a connected system requires it (a refund above your limit), or when one of your rules decides. In tool names it is an intervention.

See: Set up human handoff

Who can open a shared page (artifact visibility)

Only you (private), your team (internal), or anyone with the link (public — listed in the gallery and the sitemap).

See: Share pages the assistant makes

Allowed websites (embed origin and launch origin)

An embed origin is a website allowed to show the chat launcher; a launch origin is a website allowed to open the full-page chat with a sign-in proof. Both are settings on your workspace.

See: Serve your assistant on your own domain

Resolution (Shopify plans)

A shopper conversation the assistant handled on its own, without your team. The unit the Shopify plans count.

See: AI support assistant for your Shopify store

MCP (Model Context Protocol)

The open standard for giving an AI assistant tools over HTTPS. Specification: modelcontextprotocol.io.

JSON-RPC 2.0

The request-and-response format MCP uses. Specification: jsonrpc.org/specification.

OAuth 2.1 with PKCE

The sign-in flow the management MCP and per-customer connections use; PKCE is the check that ties the returned code to the app that started the flow. Specification: the OAuth 2.1 draft and RFC 7636.

JWT and JWKS

A JWT is the signed set of claims a sign-in proof is; JWKS is the public keys it is checked against. Specifications: RFC 7519 and RFC 7517.