Can Photon be Used for Logging Data to Meteor Server with User Accounts?

I am having trouble determining if I can use the Photon for my business configuration. Here is my setup:

I have a Meteor app which has a user account system.

I have users with ids and passwords. I want to use a Photons to log data tied to user’s account in my system.

Each of my customers should have an pleasurable/uncomplicated experience in hooking their Photon to their wireless network.

Each Photon needs the ability to log data to my site using the customers id and password for my site. This implies that the customer also have a pleasurable/uncomplicated means of customizing their Photon with the id and password for my system.

My site accepts REST or DDP communication for logging in an logging data.

I need secure communications for ids and passwords to my site.

I have invested a lot of time in determining if the Photon will meet my needs, but unfortunately I have found no acceptable way to use it. The webhooks interface has some limitations (I can explain in more detail if I get a response to this), and it doesn’t seem practical to customer-personalize each Photon with login credentials for my site.

I don’t want to throw in the towel here, but I am not sure what I can do to salvage this. I like your hardware better than my 8266 solution so I would love some help. Any suggestions???

Hey @garyo,

Jeff here, one of the engineers @ Particle. Sorry you’ve had a tough time identifying a path forward. The short answer is – yes, Particle is built to handle your use case, and with a bit of time spent getting to know our platform, I think you’ll be off to the races!

The first big piece to your configuration is that you have your own back-end server that manages your own user accounts. Great! We have an authentication option that works for this scenario, it’s called Two-legged authentication. The main idea here is that your own back-end acts as a proxy between your end-user application (mobile/web app) and the Particle cloud. You can read more about it here.

In short, your mobile/web app would manage user account signup/login/session, and each one of your users would have a corresponding “shadow customer” (customer with no password) in the Particle system. Your back-end would be configured with a Particle OAuth client that could generate scoped access tokens for your customers’ devices.

As far as for logging data, there are a few options here. The tried-and-true method of doing this is to use the event stream for your product, which is basically a firehose of events that are being generated by devices belonging to your product. Your server would listen for events coming through the event stream, and save them to your database.

The URL for a product event stream is GET Based on the data sent along with each event, you could figure out which user in your system the event is coming from , and correctly save it in your database.

The other option is to use product webhooks. This is not available quite yet, but will be sometime over the next few weeks as a beta. The idea here is that you could tell the cloud to hit your app via a HTTP request every time a device in your product publishes certain events.

Hope this is a helpful starting point. There are many people on the community who are already building complex products using two-legged auth! Don’t give up! :slight_smile:



This is the whole purpose of the particle ecosystem, but I also am having trouble understanding the data flow. If I’m not mistaken you will need to have a paid organization for what you need. Take a look at this page

Thanks for pointing me in the right direction. This does seem clear. The next step is making changes to my system to determine if this is acceptable. So, do I need to set up a paid organization in order to ptototype and test this approach?


For now, yes, you do need to set up an organization to try this out. There is a free 30-day trial period, and you can cancel if it’s not a good fit. We will likely be changing our pricing structure sometime soon so this may not be the case in the long run.