Skip to main content
This guide is for the developer, marketer, or operator who has to put the widget on a real site and keep it working across environments. If you need the product editor itself, use Widget Configuration. If you need the high-level launch flow, use Web Widget Deployment. Use one widget per meaningful website experience. That usually means:
  • one widget for production
  • one widget for staging or preview
  • separate widgets when branding, agent behavior, or privacy copy differs by site
Do not reuse one production widget everywhere if:
  • you need different allowed domains
  • different sites should route to different agents
  • the consent copy or public Trust Center differs

​
Deployment Checklist

  1. Create the widget and link it to the right agent.
  2. Configure setup, appearance, content, features, actions, and privacy.
  3. Restrict allowed domains to your intended sites.
  4. Enable public Trust Center and policy links if the widget is customer-facing.
  5. Test in preview and on the target site.
  6. Run a real voice or chat session on the live site.
  7. Check Conversations to confirm traffic is recorded as expected.

​
Staging vs Production

Treat staging and production as separate implementations.

​
Staging widget

Use a staging widget when you want to:
  • test changes on a non-production domain
  • validate agent updates before public release
  • test content, actions, and privacy copy safely

​
Production widget

Use a production widget when:
  • the domain restrictions are final
  • the consent and Trust Center links are final
  • the agent and content have already been validated
Do not point a public production site at a widget you still use for internal experimentation. Widget settings apply immediately after save.

​
Domain Restrictions

Domain restrictions are one of the most important implementation controls. Use them to ensure the widget only loads on sites you control. Good practice:
  • include your exact production domains
  • include the staging or preview domains you actually test on
  • remove old preview domains when no longer needed
See Widget Configuration for the editor details.

​
Runtime Expectations

The widget is a live frontend surface. Plan for real browser behavior.

​
What to expect

  • microphone access requires HTTPS except on localhost
  • browser privacy settings can block voice access
  • domain restrictions apply immediately after save
  • saved widget changes affect the live embedded experience without changing the script

​
What to validate

  • the widget loads on the intended domain
  • the right agent answers
  • voice or chat starts correctly
  • transcript and conversations appear in the dashboard
  • consent, terms, and Trust Center links are visible where expected

​
Privacy And Trust Center

For public-facing widgets, the privacy posture should be visible before or during the interaction. At minimum, decide:
  • whether consent is required
  • what terms text the visitor sees
  • whether public Trust Center is enabled
  • whether the linked privacy policy and subprocessors pages are current
Use Conversation Privacy Controls for the full privacy model.

​
Common Mistakes

This makes it too easy to push unfinished copy, actions, or privacy settings to the public site.
Leaving domain restrictions empty is useful during early setup, but it should not be the long-term production posture for public widgets.
The preview is useful, but the final check must happen on the real site, with the real domain, browser, and consent flow.

​
Next Steps

Web Widget Deployment

Follow the full launch flow from creation to live embed

Widget Configuration

Configure setup, appearance, content, features, actions, and privacy

Trust Center

Publish your widget privacy posture for visitors

Conversations

Review live widget traffic after deployment