Widget runtime API

Once the widget loads, it installs a window.syncanix object you can call from your own code.

What you can do

• open() — open the chat panel programmatically.
• setPosition(position) — move the launcher to another corner.
• unmount() — remove the widget from the page.
• registerComponent() / unregisterComponent() / getComponentCatalog() — register your own React components for the assistant to render, validated with a schema.
• setContext() / clearContext() — feed live host-app state (user, page, cart) into the next turn. Bounded JSON only — never secrets.
• setTokenProvider(fn) — provide the end user’s token per turn (takes precedence over the data attribute).
• setStepUpProvider(fn) — provide the step-up re-authentication flow.

Example

// Open the chat programmatically
window.syncanix.open();

// Feed live host-app context into the next turn (bounded JSON, no secrets)
window.syncanix.setContext({ page: 'checkout', cartItems: 3 });

// Provide the signed-in user's token per turn (recommended for SSR apps)
window.syncanix.setTokenProvider(async () => await getAccessToken());

What the assistant can render — and what it can’t see

The renderable surface is explicit by design: the built-in primitives, the components you register with registerComponent, and embeds from origins your admin has allowlisted. The assistant can only drive what you have deliberately handed it.

The widget never scans, auto-detects, or captures your page’s DOM into the model. Reading host-page content into an AI context is a data-exfiltration and injection surface, so live-DOM capture stays customer-mediated: you decide what is embeddable by registering it.

Loaded once

Installing the global is idempotent — if the script is included twice, the duplicate is ignored with a warning, so you never end up with two widgets.

Next steps