Bosch IoT Device Management - will be discontinued by mid 2024


The digital twin layer uses the Eclipse Ditto protocol. The protocol covers two communication channels to address two different aspects of devices and their digital representation: twin and live.


The first aspect handles the digital representation of a device or any IoT asset. This thing entity (alias digital twin) is managed with the digital twin layer and its state and properties can be read and updated. The channel to work with the digital representation is called twin.

This channel is available both at the Bosch IoT Things HTTP API and the WebSocket interface which talks the Bosch IoT Things Protocol. (The REST-like API is not scope of this specification but mentioned here to outline the context.)

Updating a digital twin via protocol


A command can be sent to the digital twin layer to request a modification of a thing. When the digital twin layer handled the command successfully, i.e. the updated thing is persisted, the service publishes an event. An event is the unit that describes a modification of a thing, e.g. a property change, or an attribute change.

When sending a command, a response can be requested. the digital twin layer (asynchronously) replies to such commands as soon as the change has been applied.

Managing the policy for a digital twin via protocol

Similar to the Policies resources at the HTTP API, you can manage the policy via protocol.

Protocol specification:


Searching for digital twins via protocol

All search filters and options described at Search resources can also be applied when employing the reactive-streams protocol for search.

Protocol specification:



The channel to work with the physical device is called live channel.

Commands, events and messages are directly exchanged when using the live channel.


Commands are defined to be used to change properties of e.g. connected device. In case a response to a command is requested, the receiver must fulfill this request. It is also always required that a live thing event is published after a command has been applied (to the device) successfully.

A message carries a custom payload and can be answered by another (correlated) message.