Web support end to end: widget, inbox, co-browse, replay

A visitor lands on your site with a problem, an agent answers it, and your QA lead later reviews how it went. That workflow touches four Orbit surfaces — the native chat widget, the Inbox, live co-browse, and session replay — and each has its own docs page. This tutorial wires them into the single path a support team actually runs. Use it as the template for standing up web-chat support.

The full pipeline

Visitor opens chat widget ──► Inbox conversation created and routed
Agent answers in Inbox ──► (if visitor is stuck) agent requests co-browse
Agent joins and guides the visitor ──► resolves the issue, ends the session
Session replay was recording throughout ──► QA reviews the full journey

The widget session that fires when the page loads is the anchor: from that moment on, capture is already recording, so co-browse and replay draw from the same visit — no extra wiring per step. Copy the embed snippet from Settings → Channels → Native chat in the dashboard — the same snippet GET /api/v1/settings/native-chat/install returns. Paste it into your site’s <head>:

<script async
  src="https://api.orbit.devotel.io/widget/v1/orbit-chat.js"
  data-widget-id="org_your_org_id"
  data-api-base="https://api.orbit.devotel.io"></script>

data-widget-id carries your widget public key — the ID it presents to the public bootstrap endpoint. It is safe to expose in page source and never a secret key (dv_live_sk_*). The script loads one floating launcher; the chat panel mounts lazily on first click so the install doesn’t measurably hurt page load. Sites with a strict Content-Security-Policy can load the same bundle programmatically:

<script>
  (function () {
    var s = document.createElement("script");
    s.async = true;
    s.src = "https://api.orbit.devotel.io/widget/v1/orbit-chat.js";
    s.setAttribute("data-widget-id", "org_your_org_id");
    s.setAttribute("data-api-base", "https://api.orbit.devotel.io");
    document.head.appendChild(s);
  })();
</script>

From npm, the same widget ships as the ./widget subpath of the Web SDK:

import { OrbitWidget } from "@devotel-orbit/web/widget";

new OrbitWidget({ widgetId: "org_your_org_id" });

Either way, one bootstrap call (POST /widget/session) mints the visitor token and the widget applies your tenant config — colors, position, greeting, business hours — without more code.

Verify: open the page, click the launcher, and send a test message. A new inbound conversation appears in the Inbox as channel web_chat.

Widget conversations land in the same unified queue as every other inbound channel. The Inbox setup guide covers channels, routing rules, macros, and SLA policies; only the route is widget-specific. Point a rule at the web_chat channel:

curl -X POST https://api.orbit.devotel.io/api/v1/inbox/routing-rules \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Web widget → support team",
    "priority": 10,
    "conditions": { "channel": ["web_chat"] },
    "action": { "type": "assign_team", "target_id": "team_support" }
  }'

Add priority rules ahead of this catch-all — lower numbers run first — and attach an SLA policy so the visitor’s first reply wait is a measurable clock (both covered in the Inbox setup guide). Queue-level routing across all channels works the same way; see Omnichannel queue routing.

3. Answer in the Inbox; escalate to co-browse

Agents work the conversation like any other Inbox thread — macros, AI drafts, and SLA badges all apply to web_chat. When text back-and-forth stops helping, ask the visitor to start co-browse from the co-browse button inside the widget panel. The live page mirrors to the Inbox over a data channel — it is not a screen share, so nothing off the visitor’s visible page is transmitted. The moment the visitor initiates, the conversation’s co-browse banner flips to “Visitor started co-browsing”. The agent clicks Join co-browse to observe the visitor’s screen, optionally requesting guided control when the visitor granted it (highlight elements, scroll, or fill form fields on the visitor’s behalf). Either side ends the session; a re-initiation by the visitor is required before it can start again. The operator endpoints and the consent model are documented in the Co-browse API reference.

4. Review the session replay afterward

While the widget is on the page, session replay records every visit in parallel with the conversation — DOM snapshots plus the click, scroll, and navigation sequence. Because capture starts at the widget bootstrap, the recording exists whether or not the visitor ever opened the chat panel. After the conversation closes — hours or days later — a QA reviewer opens the thread and the replay banner appears alongside the message history. Playing the recording back shows exactly the checkout flow the visitor struggled through. Replay and masking are tenant-owned controls. Masking happens in the visitor’s browser before anything is uploaded, and the default posture masks every input and blocks payment regions — the Session replay guide covers the retention model, the masking policy endpoints, and the purge endpoint that GDPR erasure requests map to. The Contact timeline guide is the companion view for one customer’s complete cross-channel history.

5. End-to-end example: a stuck checkout

A shopper is stuck on your checkout page and opens the widget. The widget creates an Inbox conversation, routed to the support team by the web-chat rule.

Visitor: opens chat, types “Payment keeps failing at checkout.”
Agent: replies with a macro, then — seeing the answer needs the screen — clicks Join co-browse. The visitor consented to guided control, so the agent can highlight, scroll, and fill.
Agent: highlights the shipping form, scrolls to the error message, fills the postal-code field on the visitor’s behalf, and the order goes through.
Either side: ends the session; the conversation closes with a resolution tag.
QA lead (later): opens the closed thread, plays the session replay to see the visitor’s path through checkout, and coaches the agent on the form-fill that resolved it.

Every step stayed inside the same workflow because the widget session anchored all four surfaces to one visit.

Compliance boundaries

Public-key widget traffic is the only client-side surface; everything else — routing rules, co-browse join/end, privacy policies, replay purge — runs on your API key or dashboard session. Co-browse and replay masking are tenant-owned posture controls, not platform-enforced mandates: what gets captured, how long it stays, and who can watch is configuration you own. Set the masking policy before you rely on either feature in production, and document the selectors as part of your own compliance evidence.

WhatsApp

Guides

Messaging Controls

Audience & Support Tools

Web support end to end: widget, inbox, co-browse, replay

Web support end to end: widget, inbox, co-browse, replay

The full pipeline

1. Install the chat widget

2. Route widget conversations into the Inbox

3. Answer in the Inbox; escalate to co-browse

4. Review the session replay afterward

5. End-to-end example: a stuck checkout

Compliance boundaries

See also

​Web support end to end: widget, inbox, co-browse, replay

​The full pipeline

​1. Install the chat widget

​2. Route widget conversations into the Inbox

​3. Answer in the Inbox; escalate to co-browse

​4. Review the session replay afterward

​5. End-to-end example: a stuck checkout

​Compliance boundaries

​See also

Web support end to end: widget, inbox, co-browse, replay

The full pipeline

1. Install the chat widget

2. Route widget conversations into the Inbox

3. Answer in the Inbox; escalate to co-browse

4. Review the session replay afterward

5. End-to-end example: a stuck checkout

Compliance boundaries

See also