Integration overview - Dubot Docs

The minimum browser integration

Most Dubot experiences need four things:

the CDN script with a public client token;
a stable signed-in user id;
a server-minted identity token when signed identities are enabled;
customer-owned code for the context and actions that experience needs.

Start with the SDK quickstart.

Choose only the integration needed

Need	Integration
Render a wizard, Guidance, or Resource Center	Browser SDK
Supply current account or page state	`init({ context })` and `setContext()`
Run page-local behavior	Client-side callbacks
Call the customer’s authenticated API	Session API action plus customer-owned executor
Configure Dubot from an AI client	Authoring MCP
Let an end user call approved actions from their AI client	Controlled-rollout MCP action channel
Handoff from a support platform	Customer-specific support integration

Support-platform handoff

A support system can identify an eligible request and send the customer into a published Dubot experience. The first useful contract answers:

Question	Minimum answer
What starts the experience?	A named support intent or explicit customer choice
What context is passed?	Only fields required for that outcome
How is identity proven?	Stable user id plus an agreed signed-token flow
Where does work occur?	A controlled customer-product origin
What returns to support?	Completed, stopped, error, or needs-attention outcome

Zendesk, Intercom, Salesforce, and other support products are integration categories in this documentation. Their names do not imply a generally available prebuilt connector.

Keep the boundary small

A first integration does not need a complete action catalog or broad product access. Choose one outcome, expose only its required context and operations, test the failure modes, then expand from evidence.