Deployment

One script tag, or an iframe when your CSP demands it.

Most integrations are a single tag on an existing page. Where a strict content-security policy cannot allow our API, the same tag runs the assistant inside an API-origin frame instead.

Embed models

Two ways in.

Shadow-DOM embed

One script tag, isolated styles

The default. A single script mounts the assistant inside a shadow root, so your styles and ours cannot collide. Your own header button can open it by dispatching a window event — no reference to the widget required.

  • Isolated from host CSS
  • Opens from your existing UI
  • Origin-bound public key

Iframe embed

For strict content-security policies

The same bundle loads the assistant inside an iframe served from the API origin. All widget code and network calls live in that frame; the host page carries a transparent iframe that resizes itself as the chat opens.

  • No connect-src or inline styles on your page
  • Per-tenant frame-ancestors policy
  • Auto-sizing via postMessage
The default embed
<script
  src="https://widget.opensupport.me/opensupport-widget.iife.js"
  data-public-key="pk_your_key"
  data-api-base="https://api.opensupport.me"
></script>

Multi-tenant isolation

What separates one deployment from another.

Separate keys and origins

Each deployment gets its own public key, bound to the origins you nominate. A key lifted from your page does not work anywhere else.

Scoped corpus

A tenant can be restricted to a defined portfolio or to its own private content, enforced during retrieval rather than filtered afterwards.

Independent configuration

Feature flags, prompt configuration, webhooks and pharmacovigilance routing are per tenant, so one deployment’s settings never leak into another.

Usage and billing separation

Usage events and daily rollups are recorded per tenant, so consumption and cost attribution follow the deployment.

For pharma & life sciences

The intelligence layer behind patient engagement.

Where it fits

  • Brand and disease-education websites
  • Patient support and hub experiences
  • Market access and affordability journeys
  • Patient portals and digital companions
  • Contact-centre deflection and after-hours support
  • Enterprise patient-services platforms

What your teams learn

  • Top patient questions by therapeutic area
  • Where users fail to find an answer
  • Coverage and affordability themes
  • Content and training gaps
  • Support channels offered and used, and questions left unresolved
  • Engagement trends without a medical-history profile

Questions we get asked

Straight answers.

Do we need to change our content-security policy?
For the standard embed, three entries: our script origin in script-src, our API origin in connect-src, and 'unsafe-inline' in style-src, because the assistant styles itself inside its own shadow root. Where your policy cannot allow those, the iframe variant runs the assistant, its styles and every network call inside a frame served from the API origin, so your page needs only our script origin in script-src and the API origin in frame-src. The iframe variant is switched on by request.
Can our own interface open the assistant?
Yes, with the standard embed: your own button can open, close or toggle it by dispatching a window event, with no reference to the widget code. The iframe variant runs in its own window and does not take these events.

Put it on a staging page this week.

Most first deployments are a tag on a single brand page. We will provision a scoped key and help you size it from there.

Request a demo Try it live