Advanced Integration Paths

More is available than the public manual shows

Plenom's current development page advertises several Busylight developer tool bundles beyond the public kuandoHUB manual. The important caveat is that these are access-controlled, not openly documented in the same way as the HTTP API.

1. What Plenom currently offers

The March 2, 2026 development page lists:

• SDK - Busylight UC
• USB API - Busylight UC
• HTTP Windows - Busylight UC
• HTTP Mac - Busylight UC
• Chrome WebHID SDK - Busylight UC
• JavaScript SDK - Busylight UC
• Browser Extension SDK - Busylight UC

The same page says:

• the Busylight UC SDK gives .NET developers programmatic control and includes DLLs, samples, and documentation,
• the USB API is intended for low-level device control,
• the JavaScript SDK is aimed at web application integration,
• the Browser Extension SDK includes a native messaging host app,
• the Chromium WebHID SDK supports browser-native integration without a native app or middleware.

2. What is publicly verifiable vs vendor-gated

Option	Public docs available now	What we can say confidently
kuandoHUB HTTP API	Yes	Real, documented, scriptable
Busylight UC SDK	No public technical docs on the site	Exists and is available by request
USB API	No public protocol docs on the site	Exists and is available by request
JavaScript SDK	No public technical docs on the site	Exists and is available by request
Browser Extension SDK	No public technical docs on the site	Exists and includes native messaging host tooling
Chromium WebHID SDK	No public technical docs on the site	Exists and targets Chromium browsers

3. When to request vendor access

Ask Plenom for the richer developer tools when:

• kuandoHUB is not acceptable in your deployment,
• you need direct browser HID access,
• your app must own the device lifecycle,
• you need deeper native control than local HTTP exposes,
• you are building a distributable commercial integration.

4. Best guesses about the fit

These are inferences from Plenom's descriptions, not confirmed public SDK docs:

• Busylight UC SDK: best fit for C#, C++, or Windows desktop integrations.
• USB API: best fit for embedded, driver-level, or non-standard platform work.
• JavaScript SDK: likely best for web apps where vendor middleware or helper tooling is acceptable.
• Browser Extension SDK: likely best for browser add-ons that need native messaging.
• Chromium WebHID SDK: likely best for web apps that want device access without a local helper app.

5. Practical strategy

1. Build the first prototype with the public HTTP API.
2. Decide whether kuandoHUB is acceptable operationally.
3. Only request the deeper SDKs if the middleware dependency or API limitations become real blockers.

That keeps risk low and gets you to a working prototype fastest.