The browser SDK is distributed from Dubot’s CDN. It is not published as an npm package.
Before you begin
You need:- a Dubot workspace;
- its public client token;
- a saved Test configuration or a published Production configuration to verify;
- an approved origin for the customer application;
- a stable signed-in user id;
- a server-minted identity token if the workspace observes or enforces signed identities.
1. Add the script
Place the stable SDK entry on every page where Dubot may render.Dubot.init().
crossorigin="anonymous" preserves useful SDK error details for telemetry.
The script above runs before the next script in the page. If your application loads it
asynchronously, wait for its load event before calling window.Dubot.
2. Initialize for the signed-in user
currentUser and identityTokenFromYourBackend represent values from your authenticated
application; obtain them before this code runs. Omit identityToken only when your workspace
permits unsigned sessions. See Identity and context for server signing.
init() returns a promise. Await it before a programmatic launch. A resolved promise alone is
not proof that configuration loaded: expected setup failures are logged to the browser console.
Complete the verification checks below.
3. Publish and match a surface
A configured placement mounts automatically when its page rules match. You can also render a published wizard programmatically after initialization:4. Verify the integration
In the browser console:versionidentifies the deployed SDK build rather than a localdevbuild;initProps.userIdmatches the signed-in user;initProps.verifiedreflects whether an identity token was supplied, not whether the server accepted its signature;- the expected placement or Resource Center appears on a matching page;
- Test shows the latest saved configuration and Production shows only the published version;
- a deliberately invalid origin or identity fails as expected.
Before Production
- Match the exact HTTPS product origins that should load Dubot.
- Configure the Content Security Policy destinations for the features and brand assets you use.
- Initialize only after the application knows the signed-in user and has obtained a fresh server-minted identity token.
- Send only the context and callbacks required by the active experience.
- Verify one allowed case and deliberately rejected origin, identity, and action case.
Content Security Policy
For the default production browser SDK, permit these destinations in your existing policy:
This is a destination list, not a replacement policy. Keep your application’s existing
directives and nonce or hash requirements. Brand styles, images, videos, embedded content, and
host callbacks may need their own sources. Check the browser’s CSP violation messages with the
actual published Brand and selected features before launch.