We are facing an issue while allowing customers claim the device (E-Series) via Two-Legged Authentication. I would like to get some feedback to validate if the process is implemented correctly. I am using Particle-API-JS SDK and have setup the Authentication Client & Product inside Particle Console. Our backend database stores the device information, customer information etc.
Steps to claim the device:
Customer login to our app
Start the claim process
If not an existing Particle Customer then we create Particle Customer using API /v1/products/${product}/customers
Add Device to Product addDeviceToProduct
Claim Device using customer token (This works only if the device is online) claimDevice
The query I have is how can we claim customer device even if its not online. We are facing issue while claiming the device if its not online. Our customer can activate the device to have them ready for installation or deployment which then can be installed by their team member or installer.
We tried testing with getClaimCode API as well, in which we get the claim code for the device however when the device came online, we didn’t see the customer as the device owner on Particle Console.
If E-Series device is not online, then how can we send the claim code to the device?
Customer login to our app
Start the claim process
If not an existing Particle Customer then we create Particle Customer using API /v1/products/${product}/customers
Add Device to Product addDeviceToProduct
Get Claim Code for Device using customer token (This works only if the device is online) getClaimCode
I have read through the documentation on authentication & implementation and some
I’d love to hear some insight on managing the product for customers using two-legged implementation for claiming the Electron mainly using API’s.
The query I have is how can we claim customer device even if its not online.
It is not possible to claim a device that it is not online. A cryptographic exchange is required between the device and cloud for the claim to succeed and the device must be online and breathing cyan for this to occur.
Many cellular product creators claim all devices to a single account that they control during manufacture. This eliminates the whole dealing with claim codes and claiming when the device is in the field.
Thank You rickkas7. That is the current implementation we have, however with our new update we are testing out the customer implementation which gives our smartphone app & web app to get the event stream from devices directly to the app or web app. Currently we have webhook that updates the data on our backend and then the app fetches the data from our backend.
Yes, claim codes do work on the Electron and E series. For products with mobile apps where you want the mobile app to directly communicate with the Particle cloud, it’s a reasonable solution.
(The other solution is to claim all of the device to a single account and have your own webapp manage all of the Particle cloud communication, and have your mobile app only communicate with your server.)
Note, however, the claim codes are only good for an hour, so you need to use them right away. You can’t generate claim codes for all devices ahead of time.
Thank You. I am not planning to generate claim code ahead of time. I am currently testing two alternate solution, one using claim code with SDK and one with claim device method. When devices comes online our backend will initiate claim process using claim device API on behalf of customer as we store customer token on our database.
I know that I may be complicating the process but in the long term, we are planning to integrate Particle SDK on the app side so that our customer can receive the events directly from the particle devices. Currently the app has to make continuous API calls to our backend to fetch the latest data which is not real time as we wish. Another solution is to setup socket server to send the data to apps as we receive events on our backend from particle. So instead of setting up socket, it’d better if we just have Particle SDK integrated directly in App.