Understand the boundaries
Separate device identity, business permission and observed connection state.
Integration at a glance
Build the integration
Follow runnable provisioning, Linux and backend examples from the reference kit.
Operate with evidence
Use signed webhooks and timestamps to keep support decisions grounded.
Target supported hardware and an enabled site. Your application retains its own health and recovery responsibilities.
Start here
Follow the quickstart for one device, then use the architecture and provisioning guides to plan the factory and site workflows.
Implement and operate
Use the reference adapter for the device and the scoped API clients for your backend. Add signed events and freshness-aware status reporting before production review.
Availability and compatibility
Software implementation candidate. Physical router and device qualification is pending. IoT network features are disabled by default, and production activation is reviewed by HotSpotVU. Authorized sandbox trials use a bounded service-admin test window; this does not establish production qualification.
Automatic connectivity applies to compatible, enrolled devices on explicitly enabled, supported sites with working Internet service. Local business permission is required.
The self-service sandbox default is ten devices and one explicitly authorized test site. Production activation is reviewed. OpenRoaming direction and limitations are described at /docs/iot/openroaming.
Documentation conventions
An enrolled identity is a known device. Site permission authorizes that identity at a specific location. A recent connection observation is evidence of network state. None of these, alone, proves that the manufacturer’s application is healthy.
Diagrams show intended software behavior and release boundaries. They do not certify hardware performance or third-party federation coverage.