Bosch IoT Things HTTP API
Details regarding the syntax can be found in following sections and at the REST-like HTTP API description application itself.
The interactive API documentation supports
you to instantly try it out.
In order to try it out please start by booking a free plan - see Book the Bosch IoT Things cloud service.
Please request a service plan as you will definitely need an identifier for each single API call.
The Bosch IoT Things HTTP API uses response status codes (see RFC 7231) to indicate whether a specific request has been successfully completed, or not. However, the descriptions we provide additionally to the status code (e.g. in our API docs, or error codes like. “solutions:transaction.count.exceeded”) might change without advance notice. These are not be considered as official API, and must therefore not be applied in your applications or tests.
Navigate to https://apidocs.bosch-iot-suite.com and select Bosch IoT Things - API v2 at the upper right drop-down-menu.
The entry point is https://apidocs.bosch-iot-suite.com
- Select a spec: Bosch IoT Things - API v2
This field shows the service endpoint, which differs depending on which environment you subscribed for:
https://things.eu-1.bosch-iot-suite.com/api/2for Amazon Web Services infrastructure
Find the list of all endpoints at our FAQ section How to find the endpoints for my subscription?
- Authorize: opens a pop-up-dialog with the option to specify bearerAuth (http, Bearer). This expects a JWT issued by a supported identity provider, e.g. Suite Auth.
While using the Bosch IoT Things HTTP API programmatically you will need:
- The header for authenticating your solution as described at
Authenticate as a technical client:
- The header for authenticating the current user as described at
Authenticate as a user:
- via Basic Auth:
- or alternatively with a Context ID
(which holds for example all Groups the user is member of, and all Roles assigned to the user at the time of creating the Identity Context)
x-im-context-id=<$the context ID>
- or alternatively with a JSON Web Token (JWT)
Authorization=Bearer <$ your token>
- via Basic Auth:
- The header for specifying the content type, e.g.
Migration from API 1 to API 2
In case you need to migrate a thing which was created via API 1 to API 2, please note that you need to migrate the access control list entries (ACL) into a policy, and to assign your thing to such a policy.
Request the thing to be migrated, via API 2 and use the field-selector to specify that the inline policy (i.e.
_policy) should also be retrieved.
Create a new policy from the content of the requested inline policy, with a
policyIdof your choice (e.g. same as the
Assign the new
policyIdto the thing to be migrated.
Note: Henceforth the thing cannot be read nor written via API 1.
Please make sure all other parts of your application (e.g. device integration, business UI) are using API 2 as well.