Spend less time rebuilding the connection workflow.

Choose your integration surface #

Device firmware: use the Python reference adapter on Linux with full EAP-TLS wpa_supplicant, OpenSSL, protected local keys, reliable time, and a working DHCP configuration. Embedded targets require separate adapters and qualification.

Manufacturer backend: use the Python or JavaScript client with TypeScript declarations to create products, enroll devices, issue certificates, and read scoped inventory. API base path: /api/iot/v1. Partner tokens belong only on trusted systems.

Operations backend: verify signed webhooks and reconcile current request status. Site admission remains a human business decision; a manufacturer token cannot approve access.

• Follow the first-device quickstart →
• Review architecture and trust boundaries →

Install the reference kit #

Prerequisites: Python 3.10 or newer, OpenSSL, curl, and unzip on the provisioning workstation. The optional backend client requires Node 20 or newer. The kit contains SDK sources, service templates, and the OpenAPI contract.

Set HOTSPOTVU_API to your assigned HTTPS origin with no /api suffix. Obtain a scoped, expiring partner token from an authorized company administrator and inject it as HOTSPOTVU_IOT_TOKEN. Examples do not contain live credentials.

# Run on a trusted Linux development/provisioning workstation.
# Set HOTSPOTVU_API to your assigned HTTPS service origin (no /api suffix).
# Supply HOTSPOTVU_IOT_TOKEN from your secret manager; do not paste it here.
curl --fail --silent --show-error --proto '=https' \
  "$HOTSPOTVU_API/iot/connectivity-kit.zip" -o connectivity-kit.zip
unzip connectivity-kit.zip -d hotspotvu-kit
python3 -m venv .venv
. .venv/bin/activate
python3 -m pip install ./hotspotvu-kit/sdk/python
hotspotvu-connect --help

• Download connectivity kit ↓
• Download OpenAPI 3.1 ↓

Provision the first device #

Create a product once, or reuse its UUID from the dashboard. Use its returned id as HOTSPOTVU_PRODUCT_ID. Use a partner token with write (create product), enroll (registry and credential issuance), and read (inventory and request status) scopes.

Run enrollment separately for each physical unit in a trusted factory environment. The CLI creates the registry record, generates an EC key and UUID-bound CSR locally, and installs the returned certificate, CA bundle, network profile, and device reporting token.

If provisioning runs on a workstation, securely install the individual credential directory onto its intended unit. Never clone it across devices. The manufacturer token must not ship in the device image.

curl --fail --silent --show-error \
  --request POST "$HOTSPOTVU_API/api/iot/v1/products" \
  --header "Authorization: Bearer $HOTSPOTVU_IOT_TOKEN" \
  --header "Accept: application/json" \
  --header "Content-Type: application/json" \
  --data '{"name":"Temperature sensor","platform":"Linux","category":"sensor"}'
# HTTP 201 returns the product object directly.
# Save its id as HOTSPOTVU_PRODUCT_ID before the enrollment step.

# Requires Python >=3.10, OpenSSL, and a protected per-device directory.
umask 077
hotspotvu-connect enroll \
  --base-url "$HOTSPOTVU_API" \
  --product-id "$HOTSPOTVU_PRODUCT_ID" \
  --external-id SENSOR-0001 --name "Temperature sensor 1" \
  --directory /etc/hotspotvu-connect
hotspotvu-connect configure --directory /etc/hotspotvu-connect
# Output from enroll: {"device_id":"<UUID>","credentials_installed":true}
# The private key stays local. Only the CSR is submitted for signing.
# The partner token belongs only in this factory environment.
# Exclude it from the shipped device image.

• Factory provisioning and credential lifecycle →

Integrate your backend #

Install the Python package from the kit for the first example. For JavaScript, install the local bundled package into your backend project, save the example as fleet.mjs, then run it. No public package registry release is assumed.

The inventory state field describes the registry lifecycle. Read /requests and its computed status projection for current authorization, connection state, Internet checks, and freshness. The clients paginate locally without following remote URLs.

import os
from hotspotvu_connect import Client, ApiError

api = Client(os.environ["HOTSPOTVU_API"], os.environ["HOTSPOTVU_IOT_TOKEN"])
try:
    for device in api.pages("/devices"):
        # state is registry lifecycle (active/revoked), not Wi-Fi status.
        print(device["id"], device["state"])
    for request in api.pages("/requests"):
        status = request["status"]
        print(request["endpoint_id"], status["authorization"],
              status["connection"], status["internet_reachable"],
              status["last_confirmed_at"], status["fresh_until"])
except ApiError as error:
    # Log the status, never the token or a credential bundle.
    print(f"HotSpotVU request failed: HTTP {error.status}")
    raise

# Use the extracted kit from the download step; no npm registry release is assumed.
npm install ./hotspotvu-kit/sdk/typescript
# Node >=20. After saving the next example as fleet.mjs, run: node fleet.mjs

import { HotSpotVuClient, HotSpotVuError } from '@hotspotvu/connectivity'

const api = new HotSpotVuClient(
  process.env.HOTSPOTVU_API, process.env.HOTSPOTVU_IOT_TOKEN
)
try {
  for await (const device of api.devices()) {
    console.log(device.id, device.state) // active/revoked; not connectivity
  }
  for await (const request of api.connectionRequests()) {
    const { authorization, connection, internet_reachable, fresh_until } = request.status
    console.log(request.endpoint_id, { authorization, connection, internet_reachable, fresh_until })
  }
} catch (error) {
  if (error instanceof HotSpotVuError) console.error('HotSpotVU HTTP status:', error.status)
  throw error
}

• API operations, scopes, and schemas →

Connect and observe #

Install the device adapter and Wi-Fi service in your Linux image, configure DHCP with one network manager, and start the services. On first authentication a valid identity creates a pending request at the enabled site. Ordinary Internet access starts after the business allows that device and authentication retries.

Read status.last_confirmed_at and status.fresh_until alongside status.connection. A historical connected event is insufficient to show a device as online indefinitely. SDK status and successful Wi-Fi authentication do not establish application health.

{
  "authorization": "allowed",
  "connection": "connected",
  "internet_reachable": true,
  "ap_active": null,
  "last_confirmed_at": "2026-10-28T12:00:00Z",
  "fresh_until": "2026-10-28T12:01:30Z",
  "enforcement": "applied"
}

• Install the Linux services →
• Implement signed webhooks →
• Understand business approval →

Test before production #

In an authorized sandbox, exercise first approval, automatic reconnect, permission removal, credential renewal, revocation, incorrect clocks, and loss of the Internet uplink. Confirm that stale reports stop showing as connected.

The sandbox default is ten devices and one explicitly authorized test site. Hardware qualification and site activation are required. External OpenRoaming, embedded adapters, billing settlement, and manufacturer firmware distribution remain outside the initial supported-site candidate.

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.

• Compatibility and troubleshooting →
• OpenRoaming interoperability roadmap →