This is not just a platform for IoT devices: we built nRF Cloud with both human users and devices in mind.
Although we refer to our APIs based on their technical protocols—REST and MQTT—we could also refer to them functionally as a "nRF Cloud REST API" and "User API". REST and MQTT would be applicable to both.
Supports Device-to-Cloud use cases.
What we could call the "nRF Cloud REST API" consists of that portion of the nRF Cloud MQTT API that the device has permission to use based on its IoT security policy.
The nRF Cloud REST API also consists of those REST API endpoints that are authenticated using JSON Web Tokens. To be sure, human users can also call these endpoints, but they were designed to be consumed by devices; and this is a reason we require a higher level of security for those endpoints.
Supports Cloud-to-Cloud use cases.
A "Proxy Service API" might consist of a subset of REST API endpoints that are called in order to serve a fleet of devices that are not provisioned on nRF Cloud. The main use case here is Location Services. Cloud-to-cloud use of our platform requires a special business arrangement. For more information please contact Nordic Sales.
Supports User-to-Cloud and User-to-Device use cases.
We could call the remaining endpoints of the nRF Cloud API the "User API". Humans, however, typically interface with APIs through applications, whether Web, mobile, command-line utilities, etc.
The "User/Application API" consists of that portion of the nRF Cloud MQTT API for which a user, or the application used, by them has been granted permission. These applications will run either an MQTT client (imagine a NodeJS app that uses an nRF Cloud "account device" to monitor and interact with all of that user's devices) or conduct secure MQTT communications over Websockets (e.g., the nRFCloud.com or our phone gateway).
Additionally—and perhaps most commonly—the "User/Application API" consists of those REST API endpoints that support a variety of use cases:
- building Web or mobile IoT applications / dashboards
- writing scripts for provisioning devices
- even directly interacting with devices, e.g.