> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Web support end to end: widget, inbox, co-browse, replay > Assemble one support workflow — install the native chat widget, route its conversations through the Inbox, escalate to live co-browse, and review the session replay afterward. # 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 ```text theme={null} 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. ## 1. Install the chat widget 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 ``: ```html theme={null} ``` `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: ```html theme={null} ``` From npm, the same widget ships as the `./widget` subpath of the [Web SDK](/sdks/web): ```ts theme={null} 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`. ## 2. Route widget conversations into the Inbox Widget conversations land in the same unified queue as every other inbound channel. The [Inbox setup guide](/guides/inbox-setup) covers channels, routing rules, macros, and SLA policies; only the route is widget-specific. Point a rule at the `web_chat` channel: ```bash theme={null} 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](/guides/inbox-setup)). Queue-level routing across all channels works the same way; see [Omnichannel queue routing](/guides/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](/api-reference/cobrowse). ## 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](/guides/session-replay) covers the retention model, the masking policy endpoints, and the purge endpoint that GDPR erasure requests map to. The [Contact timeline guide](/guides/contact-timeline) 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. 1. **Visitor:** opens chat, types "Payment keeps failing at checkout." 2. **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. 3. **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. 4. **Either side:** ends the session; the conversation closes with a resolution tag. 5. **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. ## See also * [Inbox setup](/guides/inbox-setup) — channels, routing rules, macros, SLA, AI drafts * [Omnichannel queue routing](/guides/omnichannel-queue-routing) — queue-level routing across every channel * [Co-browse API](/api-reference/cobrowse) — the live-session operator endpoints * [Session replay](/guides/session-replay) — retention, masking, purge * [Contact timeline](/guides/contact-timeline) — the unified customer history view * [Web SDK](/sdks/web) — the `./widget` subpath and other browser surfaces