Customer claiming devices

I’ve been banging my head against this for 2 days, and am hoping someone here can help, basically here is what we are hoping to accomplish in the way of workflow (using two legged authentication):

  1. PCB is assembled and passed on for firmware and testing.
  2. Device is “claimed” by team member, who creates a corresponding device on our site.
  3. Team member flashes firmware to device, and tests UI and basic functionality.
  4. Team member unclaims device.
  5. Device ships to customer with a key/QR code.
  6. Customer creates or logs in to account on controlanything, we create customer on organization (working)
  7. Customer uses that key/qr to associate their controlanything account with device (working)
  8. Customer “claims” device and connects it to wifi

I’ve spent a lot of time working with the UI, and dealing with flashing devices/API stuff, but have just recently started trying to work through the organization stuff. My understanding of the process leads me to believe that the way this needs to be handled is:

  1. Get claim code from POST “v1/orgs/:organization/products/:product_slug/device_claims” using team members access token
  2. Claim device using claim code from step 1
  3. Flash firmware to device through PUT “v1/devices/:device_id” (tested and working with regular user, not org)
  4. Unclaim device through DELETE “v1/devices/:device_id”

The problem is that step 2 doesn’t seem to work. I’ve tested using a team members access token, and a customers access token. While the device does connect to wifi, and the “claimed” flag on the device is set to true, I never see it in my dashboard or build as the team member, and it doesn’t show up in our product device list. When I try to fetch the device info (GET “v1/devices/:device_id”) I get:

error: Permission Denied info: I didn't recognize that device name or ID, try opening https://api.particle.io/v1/devices?access_token=undefined

I have checked and am connecting using the same access token I created the claim token with, and the device id is the one I get from the module during setup. I can go to build and claim the device, and I can “add” the device to the product through the dashboard so I know the device id is correct.

I did try flashing firmware to the device to set the “PRODUCT_ID” and “PRODUCT_VERSION” and then unclaiming it, but that hasn’t helped either.

I am currently just testing all of this with Photon modules, in case that makes any difference.

I have a finite number of Photons to test with, but am a little concerned (based on other threads) that there may be some issue with trying to claim the device as a customer AFTER it has been claimed and unclaimed by a user.

Oh hi Trey! I just had another thought too- are you adding the device IDs to the Product via the Devices interface on dashboard.particle.io? Or are you trying to add it to the Product with the team member claiming?

My first attempt I added the device through the dashboard, and it told me the Product ID didn’t match.
After that I tried flashing firmware (as the team member) to the device with the product ID and version set, which solved the error in the dashboard, but subsequent attempts to claim as customer failed (after unclaiming from team member).

I just tried, without flashing the product ID, to claim the device as a customer, but it doesn’t work. As far as I can tell, claiming the device as a team member can only be done as a user, when I try to hit the endpoint to claim the device as a product, I get an error that the Organization was not found for this customer.

One thing I did notice was in the endpoint for creating a scoped token, the “scope” field should be:

scope=customer=user@example.com

I seem to remember that “scope” is the key of the field, but just in case, tried making the key scope=customer (because the value gets URL encoded) and I still received an access key in the response. That makes some of these endpoints a little hard to troubleshoot.

I know this isn’t really the place for it, but it sure would be nice to have an “organization error log” that showed failed API requests and why they failed, for endpoints that don’t show failures (like generating a claim token with an incorrect product slug).

@zaphod-42 Can you PM me device IDs of the Photons you tested with?

One thing that I’ll add here is that because you are using the product-specific endpoint for generating a claim code, the Particle cloud will only complete the claiming of the device when it reconnects if you have previously added the device to your product (done using importing via the dashboard, as Richard mentioned). This is how the cloud knows that the device should be allowed to be claimed as the desired product.

For your particular case, it might make sense for step 1 to use the non-product claim endpoint, because you will be claiming to a team member first (not a customer of the organization).
The product-specific endpoint was designed for use with customers of your organization, not team members (Particle users).

This endpoint is simply POST /v1/device_claims, and you can find documentation here.

I would still, however, recommend that any device that will behave as your product gets imported into the dashboard before it gets into any customers’ hands. This will ensure that any other product-specific behaviors work properly.

Hi @jeiden,

That is basically what i’ve been trying to do. Attempting to claim the device as a team member through the normal method, flashing it, unclaiming it, then hitting the product claim endpoint. The problem is I have not been able to successfully claim the device as a customer, whether I add the device manually to the product through the dashboard, or flash the device with a product ID and allow it to be added automatically (it does show up in the dashboard like this). The first steps work exactly as expected every time.

@bryce Thanks, I’ve sent them over

Any other advice? I can keep trying, but I spent a good 3 days on it before I asked here and have had no luck.

Thanks for the help guys, turns out I had a typo that I overlooked (several times apparently)

1 Like