Ping device within a product (Permission denied)

Hi everyone,

I work on a project that uses the Particle Cloud API. For the past few months, we used devices without Products that could be easily pinged using the devices endpoint and an API key generated here: Particle Console | Build your connected product

$ curl https://api.particle.io/v1/devices/0123456789abcdef01234567/ping \
       -X PUT \
       -d access_token=1234

Now we have multiple Products in Particle and we still want a single place in our application where we can ping all the devices. So let’s say we get the :productIdOrSlug for each device and use the following API call:

$ curl https://api.particle.io/v1/products/:productIdOrSlug/devices/0123456789abcdef01234567/ping \
       -X PUT \
       -d access_token=1234

The problem is that we get a “Permission denied” error when using the global API key.

{"error"=>"invalid_scope", "error_description"=>"Permission denied"}

We have around 5 products and hundreds of devices. Is there a way to ping devices without having to create 5 API keys for each product?

I’m guessing that is not working because an oAuth token created for a developer account in the Authorization tab grants access only to that account, not all of the products that the user has access to.

Try creating a token using particle token create from a user who has access to all of the products as a team member and see if that works.

2 Likes

Thank you, Rick! It worked, but the token expires New access token expires on Wed Jul 07 2021 13:18:24 GMT+0300 (Eastern European Summer Time)

We are doing server-to-server calls, re-generating the token each time is not ideal.

And in the future, if we enable MFA on the root account, it will be problematic.

You can create a non-expiring token from the CLI using

particle token create --never-expires

This also works if you have MFA enabled. The reason is that MFA is tied to the user login procedure, so you’ll need to log into the Particle CLI using MFA if it is enabled. Once you generate a token, that token represents the capabilities of that logged in user, and does not need to be re-authenticated with the MFA token. Consequently you’ll want to make sure that token stays safe, especially if non-expiring.

If you want to use expiring oAuth tokens, which would be a more secure option, you need to do it per product, since the oAuth client secrets are per-product.

1 Like

Thank you, Rick! That was the solution I was looking for.

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.