Architecture and SDK Map

Start with the control surface

For most teams, the first question is not "which language?" but "am I talking to kuandoHUB, to a browser bridge, or directly to the device?"

1. Integration layers

Your app or script
        |
        +-- HTTP requests to kuandoHUB
        |
        +-- Vendor JS SDK / Browser Extension SDK / WebHID SDK
        |
        +-- Vendor Busylight UC SDK
        |
        +-- Vendor USB API
        |
Busylight hardware

The public manual documents the kuandoHUB HTTP path best. That makes it the safest path for real-world development unless you already have access to Plenom's developer packages.

2. Decision table

Need	Best path	Why
Flip the light from a script today	HTTP API	Publicly documented, works from any language
Add BusyLight to an internal web app quickly	HTTP API from browser or local desktop helper	Lowest friction
Build a browser-only native experience	Chromium WebHID SDK	Promising, but vendor access is required
Integrate with a native Windows desktop app	Busylight UC SDK	Likely strongest fit for C# / C++
Do low-level hardware control	USB API	Most flexible, but also most specialized
Build something cross-platform with minimal vendor friction	HTTP API	Verified docs, simple deployment

3. When JavaScript makes sense

Use JavaScript or TypeScript when:

• the control point is a web app or Electron app,
• you want quick automation in Node.js,
• your system already has local webhooks or dashboards,
• you can rely on kuandoHUB running locally.

JavaScript is especially good for HTTP-based integrations because the payloads are simple and the API is local.

4. When Python makes sense

Use Python when:

• you are building local automation tools,
• you want cron jobs, daemons, or service monitors,
• you already have monitoring or ops scripts in Python,
• you want to bridge APIs, databases, and Busylight state quickly.

Python is the best scripting choice for server-like local automation around Busylight.

5. When native SDKs make sense

Use the vendor SDK or USB API when:

• kuandoHUB is not acceptable as middleware,
• you need tighter device control than the documented HTTP API offers,
• you need enterprise Windows desktop integration,
• you want browser-native HID access with no local HTTP service,
• you are prepared to request Plenom's developer tool bundles.

6. Practical recommendation

Start with kuandoHUB and the HTTP API first.

Move to vendor SDK access only if:

• you hit a documented HTTP limitation,
• you need direct device control,
• your deployment architecture forbids the local app dependency,
• you want browser-native HID instead of a local HTTP listener.