This section introduces the nRF Cloud REST API.
If you are not familiar with REST APIs, start with the Postman Learning Center.
The nRF Cloud REST API
- In any web browser, open and download https://api.nrfcloud.com/v1/openapi.json.
- In any REST tool, GET https://api.nrfcloud.com/v1/openapi.json.
- At the top of the API reference introduction page, click the Download button.
REST tools, such as Postman or Insomnia, can parse the downloaded file and create a collection of endpoints for you.
See also Using the REST API.
The REST API authenticates users with an API key, and devices with a JSON Web Token (JWT). Only a subset of the nRF Cloud REST API endpoints should be called by devices instead of users. These endpoints indicate
JSON Web Token in the
Authorizations section. Otherwise,
Simple Token is indicated.
Some endpoints, like FetchCurrentPendingFOTAJobExecution, support both schemes.
Tokens and keys
Authenticating requests to nRF Cloud involves tokens and keys.
A token is used to authenticate a request to the nRF Cloud APIs:
- An API key.
- An evaluation token, a specific kind of JWT for Location Services.
- A JWT.
A key can refer to the following:
- A public or private key used to sign a JWT.
- A service key used to sign tokens for Location Services.
Some requests to the REST API require a simple authentication token in the
Authorization header. Here is a cURL example of this header:
-H "Authorization: Bearer d8be845e816e45d4a9529a6cfcd459c88e3c22b5"
The API key functions as a token, not a key. In some API references, it is referred to as a simple token.
See how to generate and retrieve API keys in the nRF Cloud portal.
This token is used for endpoints and operations other than Location Services and FOTA. This type of token does not need to be signed with a key.
The API key is also used to authorize requests based on user role.
An evaluation token lets you and your team try nRF Cloud Location Services free for thirty days. The trial period starts once you generate the token. Once the trial period is over, you need JWTs signed with service keys.
The evaluation token is a type of JWT and used in the same way. See Using JWTs in requests for more information.
See how to set up a plan that includes access to Location Services. If you are using an evaluation token, you do not need to separately generate service keys. All applicable services are enabled for all devices automatically.
REST endpoints intended for devices or proxy servers require a JSON Web Token (JWT). A JWT authenticates a request to a service from a device, so nRF Cloud can verify that it is from that device.
A distinct JWT is required for each Location Service (A-GPS, P-GPS, and ground fix), as each requires the relevant service key.
The payload for each JWT depends on the type of key used:
|Signing (private) key||Payload|
|Device key||The |
|Service key||The |
JWTs generated by the modem automatically contain the device UUID in the payload's
iss claim. This is useful if your device uses its UUID as its device ID, in which case, you can omit the
If your device uses a different value for the device ID, you must provide that value as the
subject claim of the JWT. For example, if you want to use JWTs on Nordic Semiconductor products that have a device ID formatted as
nrf-[IMEI], as is the case for the nRF9160 DK and Thingy:91, you must either provision a new certificate that uses the UUID (and re-provision the device on nRF Cloud), or pass the
nrf-[IMEI] ID as the
subject to the
Using JWTs in requests
Add the generated JWT to the
Authorization header as a
Bearer token. Here is a cURL example:
-H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJkZXZpY2VJZGVudGlmaWVyIjoiZmIwOWNkZmItZTY4Yy00NGUzLWIwMTQtMmJlZDc4Yzk3OTQ5In0.RUAWePWjqRn4TK6EXsiKrsMM69FqDjg7dn52hrqG8CM"
Signing (private) and verification (public) keys
When a JWT is received by an nRF Cloud endpoint, its digital signature must be verified by the corresponding public key.
nRF Cloud supports two types of private keys:
- Device key: generated on the device and unique for each device.
- Service key: generated by nRF Cloud and unique for each service, such as Location Services. This is typically only used for proxy servers. Use of service keys requires a Pro or Enterprise plan.
nRF Cloud obtains public keys in one of the following ways:
- Device key:
- Upload the key manually with the
- nRF Cloud automatically extracts the device key from the device's non-JITP certificate during the provisioning process.
- nRF Cloud automatically extracts the device key from the device's JITP certificate, if applicable and no other public key can be found to verify the signature.
- Upload the key manually with the
- Service key: nRF Cloud generates and stores service keys on demand through the nRF Cloud portal.
Service keys allow you to use each component of Location Services with a proxy server. A service key can be public or private.
Each component (A-GPS, P-GPS, and ground fix) requires a service key. Once you generate a key for each component, you need to generate a new JWT for each service that is signed with the corresponding service key. This requires a Pro or Enterprise plan.
If you are using an evaluation token, you do not need to generate service keys.
REST client tools
Use cURL or other utilities to call APIs from the command line.
API endpoints that change existing resources, such as
UpdateDeviceName, allow you to include an optional
If-Match header to avoid lost updates.
The value for this header is taken from the
$meta.version property. The value is also available in the
ETag for endpoints that return a single resource, for example,
If the version you pass is not equal to the latest version of the resource, you get an
HTTP 412 and
See the following guides for next steps: