Product webhooks


I’m developing a product and a question about product webhooks.

Here is some background info:
We are using Webhooks for device-to-app communication. We want to be able to send data to the device and screen it when it enters the app. Currently, I’m using a generated access token that is in the webhook header, like so:

"headers": { "Authorization": "Token <access_token>" },

When my app receives the webhook payload, I can reject it if it doesn’t have the appropriate access token. This works with my account because I can dynamically edit the webhook from the app, but when I try to make a product webhook, I am no longer able to dynamically edit the webhook.

Is there an established way that people receive webhook payloads from their product webhooks?

1 Like

I’m not completely sure I understand your use-case, however my first suggestion is to turn things around and use the Server Sent Events stream from your app (I assume you mean a webapp, not a mobile app) directly into the Particle cloud.

With SSE you make a single authenticated TLS encrypted connection from your app to the cloud and leave it open. The cloud pushes the events directly down this connection as they arrive. There isn’t a need to check the access on each incoming event (as in webhooks) because the connection itself is secure.

There are more tips on using SSE here:

1 Like

And if you want to stick with webhooks, you can change your product webhook from the API. You just need to use the product webhook endpoint and use a product bearer token, not your regular user access token, as described in authenticating product APIs.

1 Like

Server Sent Events sound really slick. I chose to build the webapp in rails (maybe a bad choice), so using the JS SDK may be harder.

Do you know if it would be possible to use Server Sent Events in Rails? Or alternatively, would running a node script from the Rails server be a viable alternative?

If no to both of those questions, then, at least for now, I think it might be better to stick to product webhooks.

By the way, thanks for making so many great resources!

From the link you provided:

In order to use the APIs you need a product bearer token.
So, I assume this means that all that I need to change is logging in with my bearer token credentials instead of an access token?

I have been using this gem and currently interacting with webhooks that way. When I create a Particle client that way, I am following this approach:

# Provide acess token as an environment variable

# Or configure global authentication credentials
# If you use Rails, you can put this in config/initializers/particle.rb
Particle.configure do |c|
  c.access_token = "38bb7b318cc6898c80317decb34525844bc9db55"

# Or pass access token when creating a client
# If no token is passed to, the global or environment one is used
client = "38bb7b318cc6898c80317decb34525844bc9db55")

If I'm understanding this right, I could substitute my user access token with the bearer token to create a new client. And carry on from there?

Correct, you just use the product bearer token that you can generate with the curl command and use that in place of your regular developer access token, and that will grant you access to product-level features.

I’m not a rails developer, but it looks like it’s pretty simple to do; I saw a bunch of examples.

I’m a huge fan of the SSE stream and I use it from Java (not Javascript) most of the time. The functionality is available on most platforms.

@rickkas7 That is great news! I’ll have to do some digging for a Rails example.

How many bearer tokens should I be expecting to handle at a given time? Reuse the same token for all the accounts until it is time to refresh?

Well you have one token for the product itself, and if you need to impersonate a two-legged shadow customer, one for each of those.

The main reason you need an customer impersonation token is if you need to publish a private event to the customer’s device. Also you need it once for device setup.

You should be able to make other calls API using the product-level token and not need one for each customer.

1 Like

This worked well! Thanks so much

1 Like