Devices
Devices are the operational targets for telemetry, state tracking, commands, firmware workflows, and Marketplace installs. A device record binds a physical or logical device to an organisation, board, MCU identifier, Infuse deviceId, and metadata.
Device IDs are also used in Marketplace checkout and purchase APIs when a customer buys products for specific devices. Backend services should treat Infuse IoT as the source of truth for the deviceId values passed into Marketplace and downstream data workflows.
Device Identity
Infuse IoT supports several lookup paths because different systems know different identifiers:
| Identifier | Typical use |
|---|---|
id | Internal UUID-style record identifier used by backend systems. |
deviceId | Device-facing Infuse identifier, represented as a 16-character hex string in RPC workflows. |
mcuId | Hardware MCU identifier reported by the device. |
| SoC and MCU ID | Hardware lookup when discovering or reconciling a physical device. |
boardId | Links the device to a board profile. |
organisationId | Scopes the device to the owning organisation. |
metadata | Product-specific fields such as serial number, customer assignment, deployment site, or hardware variant. |
Boards, Networks, And Metadata
Boards describe hardware families or product profiles. Use board records to group devices and define board-specific metadata fields. Networks describe connectivity or deployment groupings where your backend needs that separation.
The common registry flow is:
- Resolve or create the owning organisation.
- Resolve or create the board profile for the device family.
- Resolve or create a network if your deployment model needs one.
- Create the device with
mcuId,boardId,organisationId, and optional metadata. - Store the returned identifiers in your backend system so downstream workflows use the same device identity.
State And Route Context
Device state is the latest operational view Infuse IoT has for a device. It includes timestamps and may include route details such as the last interface or UDP address seen for the device.
Last-route lookups are important for downlink workflows. If an RPC is sent immediately, Infuse IoT can use the device's last known route. If you choose a wait timeout, Infuse IoT can wait for the device to send a packet before sending the RPC.
Useful Endpoints
| Task | Endpoint |
|---|---|
| List or create devices | GET /device, POST /device |
| Read or update by record ID | GET /device/id/{id}, PUT /device/id/{id} |
| Read by device ID | GET /device/deviceId/{deviceId} |
| Read by SoC and MCU ID | GET /device/soc/{soc}/mcuId/{mcuId} |
| Read state by record ID | GET /device/id/{id}/state |
| Read state by device ID | GET /device/deviceId/{deviceId}/state |
| Read last route | GET /device/deviceId/{deviceId}/lastRoute |
| Read routes for many devices | POST /device/lastRoute |
| List devices and state together | GET /device-and-state |
For request schemas and response shapes, see the Infuse IoT API reference.