Embedding Remote Control in Your Own Product

If remote control is a tool your own team uses, installing a client is enough.

It becomes a different problem when remote control has to be part of the product you ship — a device manufacturer wanting built-in diagnostics, a SaaS vendor wanting support staff to take over a user’s screen from the admin console, an operations platform wanting a one-click connection from the ticket it is already open on.

WorksLink exposes three integration surfaces for this. Work out which end your system sits on and the choice follows.

The three surfaces

	What you integrate	Your system acts as
Client SDK	The ability to be controlled	Controlled end
Web SDK	The ability to initiate control	Controlling end
REST API	Connection logs, recordings, SSO	Data and identity

Client SDK — your software becomes the controlled end

Embed it into software that needs remote control capability, and any machine running your product can be connected to.

This is the surface for device manufacturers and software vendors. Your product is already installed on the customer’s machine. Asking them to install a separate remote control tool before you can help is an extra step at the worst possible moment — the point where something has already gone wrong and patience is short.

Building the controlled end into your own installer removes that step entirely.

Web SDK — your web app becomes the controlling end

Embed it in any web application to give your system the ability to start sessions.

The typical users here are ticketing systems, support consoles and operations platforms. Your engineers are already in your system working the problem; remote control should be a button on that page rather than “open another application, find the device, connect”.

Those intermediate steps cost more than the time they take. Every application switch is a context handoff — ticket number, device identifier, fault description all get re-entered by hand, and a mistyped identifier connects someone to the wrong machine.

REST API — pull the data, join the identity

Three uses:

Connection logs — who connected to which machine, when, and for how long
Session recordings — the screen record of a session
Single sign-on — so nobody maintains a separate set of WorksLink accounts

The first two matter because audit data is only useful where your auditors already look. Connection logs sitting in the remote control vendor’s own console are one more place to check at review time. Pulled into your ticketing or compliance system, they actually get read.

The third is account hygiene: when someone joins or leaves, provisioning and revocation should happen in one place.

Choosing

Rarely one of the three — usually a combination:

What you want to do	Surface
Add remote diagnostics to your own product	Client SDK
Take over a machine from your ticketing system	Web SDK
Both ends are your own systems	Client SDK + Web SDK
Push audit data into your compliance stack	REST API
Avoid a separate account directory	REST API (SSO)

A common full combination is a manufacturer running its own support operation: the Client SDK ships controlled-end capability inside the product, the Web SDK lets support engineers start a session from the ticket, and the REST API writes the session record back to that ticket. The customer installs nothing extra, and the engineer never leaves the ticketing system.

What the integration looks like

Client SDK

Cross-platform — Windows, Linux, macOS and other mainstream systems — with support for mainstream programming languages.

One point deserves calling out, because it looks like a contradiction against our download page: the standalone WorksLink client currently ships for Windows and macOS only (see the platforms FAQ), but the Client SDK is cross-platform.

They are different things. The standalone client is finished software we package; the SDK is capability embedded in your software. So if your product runs on Linux, integrating controlled-end capability through the SDK works — even though there is no standalone Linux client yet.

Web SDK

Works in mainstream browsers with no plugin to install.

Requiring a plugin matters more in practice than it sounds. Plugin-based approaches routinely fail at the customer’s endpoint management policy, and every major browser release is a chance for them to break.

REST API

Retrieval is pull-based — your system calls the endpoints to fetch connection logs and recordings when it needs them. There is no webhook push.

Design around this: if you want “archived to the ticket the moment the session ends”, that polling job lives on your side, not ours.

Authentication

Authentication uses an appKey and secret pair, issued by your account manager when the integration is provisioned.

The secret is a server-side credential, and where it lives and how requests are signed comes with the onboarding documentation. Settle that question early: the answer determines whether your integration needs a server-side relay, and finding out late means reworking the whole call path rather than one component.

Editions, provisioning and pricing

Integration is available on Team and Enterprise editions; Free and Personal do not include it — consistent with the pricing page comparison.

It is not self-serve: provisioning goes through sales, and an account manager issues the credentials. That is unlike most features here, so budget a step for it when you plan an integration.

Technical documentation currently comes with onboarding; there is no public version yet.

Pricing is per concurrent channel, not per user. That distinction matters most in integration scenarios: the number of endpoints you reach can be very large while the number of simultaneous sessions stays small, so you pay for actual concurrency rather than installed base.

Talk to us — tell us your scenario, which end your system sits on, and which data you need to retrieve. An account manager and an engineer will take it from there, including credentials and documentation.

For bulk deployment, device grouping and on-premises questions, see the enterprise deployment FAQ.