A screen-share link is the wrong tool for most support tickets. The customer has to install a viewer, or fumble a browser permission prompt, while the agent watches everything on the screen: other browser tabs, an email client, a password manager drop-down. Co-browse takes the narrower path: the agent mirrors just the browser session the customer started support from, launched from inside the chat widget, with masking applied before anything leaves the browser. On Devotel Orbit, co-browse ships as a built-in surface of the contact-center platform alongside video and broadcast in the RTC pillar.
This guide walks through where co-browse outperforms screen-share, how Orbit's co-browse session model works end to end, the privacy controls that decide what the agent can see and touch, and how the session pairs with voice and chat in the inbox. Every capability named here maps to the shipped product surface: the public co-browse API under /api/v1/cobrowse and the chat widget it launches from.
Co-browse vs screen-share: when the narrower view wins
Screen-share publishes a video of pixels. Co-browse mirrors the page itself; in Orbit's case, the serialized DOM of the page the visitor is on. That single difference drives most of the tradeoffs:
- Smaller surface. The DOM mirror stays inside the page. Other tabs, other windows, the email client: never transmitted. A customer who forgot to shield a personal document leaks nothing.
- Masking before transmission. Because the packet is DOM, the capture client can redact field values in the visitor's own browser before publishing anything. Screen-share masks after the fact, which usually means never.
- Low bandwidth, works on the customer's connection. DOM snapshot and mutation packets are tiny compared to a pixel stream; the session survives a weak uplink that would make video unusable.
- Structured guidance. The agent's actions are specific packets (highlight this element, scroll to this section, fill this field) rendered into the page, not a cursor floating over a video.
Screen-share still wins when the agent needs to see outside the browser tab: a desktop application, a file viewer, an OS dialog. For support that lives in the web portal, which is where most digital-support sessions end up, co-browse is the better match, and the privacy story lands better with the customer's security reviewer because masking happens before anything leaves the browser.
How Orbit's co-browse session works
The co-browse session runs on the same media real-time edge as Orbit's video pillar, but the token both parties receive is a data-channel grant with audio and video publish switched off. The lifecycle has three states (requested, active, ended), and the session record lives on the conversation it belongs to, so the inbox sees it as part of that contact's timeline.
1. The visitor starts it from the chat widget
Post the request against the conversation your native widget opened:
curl -X POST "https://api.orbit.devotel.io/widget/conversations/<conversation-id>/cobrowse" \
-H "Content-Type: application/json" \
-d '{"visitor_id":"<widget visitor id>","control":true}'The visitor picks up front whether the agent may only observe or may also guide (control). The API stamps the session on the conversation, mints a short-lived data-channel joining token bound to the room name for exactly this organization, conversation, and session, and returns the token, the media socket URL, and the session record. Token lifetime is 30 minutes; the SDK re-mints on reconnect, and a leaked token buys a join to one bounded room and nothing else.
The room name encodes the organization, conversation, and session id, so a token can never be replayed against a different tenant or a stale session.
2. The agent joins from the inbox
The inbox conversation panel polls the co-browse state for the conversation:
curl "https://api.orbit.devotel.io/api/v1/cobrowse/<conversation-id>" \
-H "X-API-Key: YOUR_DEVOTEL_API_KEY"When a session is requested or active, the agent joins:
curl -X POST "https://api.orbit.devotel.io/api/v1/cobrowse/<conversation-id>/join" \
-H "X-API-Key: YOUR_DEVOTEL_API_KEY" \
-H "Content-Type: application/json" \
-d '{"control":true}'The effective control grant is the AND of the agent's request and the visitor's stored consent: an observe-only session can never be escalated to guided control by a client that didn't ask at session start. The mint enforces it in the token grant, not the UI. The response ships the joining token, the session flipped to active, and the tenant's privacy policy, the same masking rule both sides receive at session start.
3. The agent guides with highlight, scroll, and form-fill
With control granted, the agent sends guidance packets:
curl -X POST "https://api.orbit.devotel.io/api/v1/cobrowse/<conversation-id>/control" \
-H "X-API-Key: YOUR_DEVOTEL_API_KEY" \
-H "Content-Type: application/json" \
-d '{"action":"highlight","selector":"#submit-button"}'Three actions: highlight, scroll, and form_fill. Only form-fill writes a value into the page, and the server guards every packet against the tenant's privacy policy before it broadcasts. A packet that targets a blocked region is refused with COBROWSE_CONTROL_BLOCKED and logged. Form-fill successes are logged too, since writing a value into the customer's page is the sensitive step.
4. Either side ends it, and both sides see who did
The visitor can end from the widget; the agent ends from the inbox. The session flips to ended with the terminating party recorded; both ends render an honest "ended by you / ended by the agent" state. An ended session can only be re-initiated by the visitor, from the widget, as a fresh consent.
Privacy: tenant-configured controls with a non-negotiable floor
Co-browse privacy in Orbit follows the same posture as session replay: the compliance tools are owned and configured by the tenant. Orbit provides the controls, and the tenant decides which apply within the hard floor. You configure the policy through the co-browse privacy API, and both parties receive it at session start.
mask_all_inputs(default on): every text field value is redacted in the visitor's browser before a DOM packet is published. The server never sees the un-redacted DOM.allowlist_selectors: when masking is relaxed, only these CSS selectors publish unmasked; everything else stays masked.block_selectors: tenant-added CSS selectors whose subtree is never published and can never be targeted by an agent control packet.blocked_input_types: block by input type; telephone, email, and card-number categories are blocked by default.unmask_on_visitor_click: an opt-in affordance that lets the visitor reveal a masked field on their own screen; it never changes what is transmitted to the agent.
The hard floor applies regardless of tenant config: password-type fields and the always-blocked selectors (password inputs, card-number and card-security fields, and any element tagged with the co-browse block attribute) are never transmitted and never controllable. Tenant config can only add restrictions, not remove these. A tenant that never opens the settings panel still runs the default-deny policy: masking is maximal until an operator explicitly relaxes it.
Control attempts that target a blocked region, and any form-fill the agent completes, are written to the audit log, so the blocked boundary is traceable, not just enforced.
Pairing co-browse with voice and chat in the contact center
The pairing that sells co-browse to a contact-center team is the one where the conversation already exists: the customer arrives over the native chat widget (or mid-call, with the agent opening the widget link for them), and the agent escalates from "which box do you mean?" to "I can see the form now; let me highlight the field to fix." The agent starts the co-browse session from the inbox conversation panel, and the customer clicks one consent prompt in the widget. No viewer install, no meeting link.
Because the co-browse session is stamped on the conversation, the session (who joined, when it started, when it ended, which side ended it) reads back from the same contact timeline the call recording and the chat transcript live on. For a support org running the contact-center software pillar, that consolidation is what turns co-browse from a tool agents remember to use into a step inside the contact they were already handling. The privacy policy the inbox surfaces before the agent joins means compliance review happens per-tenant, not per-ticket.
Frequently asked questions
What is co-browse, and how is it different from screen-share?
Co-browse mirrors the live page DOM of the browser session the customer started support from instead of publishing a video of pixels. The page DOM is mirrored, PII can be masked in the visitor's browser before any packet is published, and guidance actions (highlight, scroll, form-fill) are structured packets rendered into the page. Screen-share is for seeing outside the browser tab; co-browse is for the web portal where most digital-support sessions live.
How does the customer start a co-browse session in Orbit?
The visitor posts POST /widget/conversations/:id/cobrowse from the native chat widget, choosing at session start whether the agent may only observe or may also guide. The agent then joins from the inbox conversation panel with POST /api/v1/cobrowse/:conversationId/join.
Can an agent ever get guided control if the visitor only consented to observe-only?
No. The effective control grant is the AND of the agent's request and the visitor's stored consent, enforced in the media joining token's grant itself, not only in the UI. An observe-only session cannot be escalated.
What does the privacy policy actually control?
It decides what the capture client redacts in the visitor's browser before publishing a DOM packet: mask-every-input by default, with tenant-tunable allowlist, block-by-selector, and block-by-input-type lists. The server also guards every agent control packet against it before the packet is broadcast. Password fields and the always-blocked selectors are a hard floor that tenant config cannot relax.
Where do co-browse sessions show up in the contact record?
The session is stamped on the conversation the visitor started from, and the audit log records agent joins, session ends, blocked control attempts, and completed form-fills, readable alongside the chat transcript and any voice recording on the same contact timeline.
Where to start
If your agents are still emailing screen-share links to portal customers, try one co-browse session from the inbox's chat widget and time the difference. The contact-center software overview shows where co-browse sits next to voice, chat, and video, and the docs cover the widget request and agent join calls step by step.
- Contact center software: the channel side, with chat, voice, video, and co-browse in one inbox.
Published 28 August 2026.