Particle user accounts architecture for products

Hi all,

After considering many other options we’re looking forward to basing our new project on the Photon.

Now, after reading through the documentation several times I’m still not entirely clear how the devices are “owned” and basically the way devices and user accounts are managed and initially set up.

We are developing a product that is powered by the Photon P1. We will use the iOS SDK to create a branded App that provides for at least WiFi configuration to be set up on the Photon.

At the factory, when a product is ready for provisioning, we will need to set it up and load our software code on it. Does this mean the Photon will need to be linked/claimed/“owned” by our own Particle account? How will this work with the end user creating their own Particle account at the WiFi configuration stage? Will we be able to lock down the Photon to be managed only by our account, so that we can continue to push software updates to the device?

I guess what I’m after is some kind of guide from an integrator’s point of view.

Many thanks.


@neo12ibraheem thanks so much for your post! I’m Jeff, one of the software engineers at Particle. Your questions are spot on, and we are making a big push right now towards making this process as easy as possible for product creators.

Currently, our team is working on a beta version of a dashboard for organizations, equipping product creators with the tools they need to view and manage groups of devices identifying as a product. Here are some highlights of what you’ll be able to do with the organization dashboard:

  • Allow your customers to claim their devices individually instead of you needing to “own” all of the devices
  • View and manage firmware running on groups of devices
  • See lists of your devices and customers for a given product
  • Manage a team of people in your organization, and their permissions
  • Get a live stream of activity coming from all of your devices belonging to a product
  • Much much more!!

As far as the questions on manufacturing, the dashboard will give you the flexibility to either program your devices on the line, or send over-the-air firmware updates to your devices on customer setup. @zachary knows all about that if you have more detailed questions about manufacturing.

I would highly suggest that you request an invite to join the beta once it’s released. To do so, log into the dashboard and click on the “+ New Organization” button. This will take you through the steps of how to request an invite.

Does this help answer your questions? Let me know if you have more specific things you’re wondering about, and I can certaintly dive in deeper.




:+1: :exclamation:

Definitely sign up for that organization dashboard @neo12ibraheem! You should probably also start a conversation with

Anyone out there in the community who’s building a consumer or industrial product on the Particle platform should take the above steps. We want you to establish an organization in our system; each organization can have multiple products.

You compile product IDs and firmware versions into your code on the Photon/P1/P0 with macros at the top of your app like this:

PRODUCT_ID(0);       // zero is the Core ;-)
PRODUCT_VERSION(0);  // zero is the first factory firmware you ship

Part of the org & product onboarding process is that we assign you a product ID to compile into your firmware, so that the devices report their product ID to the cloud. That way, you can go to your organization dashboard and oversee your products in the field. This is an entirely orthogonal mechanism to the customer claiming/owning the device. As a member of a verified organization, you can manage your fleet of products as described on our manage page.

Everyone go forth and make awesome things!

Your bouncy, lovable Particle CTO,

PS — I’m so legit. :stuck_out_tongue:


Thank you @jeiden and @zachary for your responses. I would recommend adding a page to your documentation to ellaborate on your product creation architecture, tools and processes.

I will sign up for the Organisations and start a conversation with sales per your advice. Do you have an ETA for the first beta version?

So if I’ve understood, essentially your servers will be able to identify a device as belonging to a particular organisation and product through the PRODUCT_ID() call in the device’s firmware.

I understand how this is “orthogonal” to the customer claiming/owning the device, but I have further points here:

  1. Our customer will manage their device through our own Cloud App, which in turn will send RESTful requests to the Particle Cloud Api.
  2. Furthermore, they may have several devices in a single “installation” that will work together but need to be managed together as a group. Our Cloud App will allow for this and send the relevant Particle Cloud Api requests for each device in the group as required.
  3. They will therefore (should) not have any direct communication with Particle. It is silly for customers to have to sign up for an account with our App AND also an account with Particle. In fact it would be best they do not know at all about Particle, and anything Particle-related should be behind the scenes. So even though the management aspect is “orthogonal” and we should be able to manage devices regardless of what the customer ends up doing, we wouldn’t want it to be a necessity for the customer to claim/own the device, or have any involvement with Particle at all for that matter. Particle should be a “service provider for managed hardware and associated software and services that provides control and management of the hardware” in this scenario, the key here being “service provider” to the product manufacturer, not the manufacturer’s customer.
  4. I’m not familiar with the exact technical details, but building on point 2 above I would think that the easiest way to get this done is to allow for a Product Id to be entered into a branded App. That Product Id would then mean no Particle username/password is required. On connection to the Particle Cloud the Product Id is presented and the correct firmware will be downloaded OTA. The customer would also create an account or login to their existing account on our own Cloud App, and the branded App would notify our Cloud App of the new device Id, so that we can associate the device with that particular customer. Essentially, the branded App would create an account on our Cloud App instead of the Particle Cloud. If the Particle Cloud must have a username/password associated with every device, then we can create a login that is associated with our customer’s account on our Cloud App, and proxy through the creation of the account on the Particle Cloud.
  5. Then, for non-organisation devices, if the Product Id is not present (i.e. your generic Photon App), then the customer would be required to sign up for a Particle Cloud account.

I hope you follow my slightly long-winded post! We’ve reviewed several platforms like Particle and the cleanness and openness of Particle has won us over, but there needs to be a clear way for product creators to address these needs.

Thank you for your quick responses, looking forward to your input!


1 Like

Hey @neo12ibraheem, we likely will be rolling out invites to the private beta for organizations over the next few weeks. The tool is still under heavy development, however, and we are looking for people who have a strong need to have it in their hands ASAP (you seem like one of those candidates :smile: ).

As for your questions: When you create a product via the dashboard, part of the setup process will be answering a number of questions about how you would like to configure that product. One part of your product setup process will deal with authentication. Specifically, how you would like to handle your customer accounts.

One of the options that will be available will be a method called “Two-legged auth,” which, on a high level, allows you to manage all of your customers’ accounts on your own server, while hiding Particle completely from the customer. Leveraging the oAuth spec, Two-legged auth will allow you to generate scoped access tokens for each of your customers in order to programatically read data from and take action on their devices. This will involve creating a new “account” for each new customer when they are added to your database. I put “account” in quotes because with this authentication approach, there will be no login password like a traditional user account. This account will only exist so your app can generate access tokens for that particular person, to communicate directly with the Particle API.

This method of authentication will not be released when the initial organization dashboard is released. This is on our development roadmap over the next few weeks/months. We look forward to working with product creators on making sure that authentication works for their needs, whether they’d like Particle to be visible or not.

And, you are spot on with documentation. As things are released into the wild, we will be adding an organizations section to the docs that should help explain all of this clearly.



Thanks @jeiden, I’ve put in a request to join the Beta program, as you say we are in desperate need for this - actually it is more of can we actually base our product on Particle or not?

The OAuth mechanism sounds ideal, we will be using 2-legged auth ourselves for our own Api, so it shouldn’t involve much to work this in to our workflow when it is ready. We’re still waiting for our first test Photon to arrive, so I’m sure we can afford to wait a few weeks :wink: It will be a few months before we will be ready for production, so as long as months don’t become years this should be a pretty good solution. Having a general idea of how Organisations/Organi zations fit in to the Particle platform and being able to get to grips with the tools and test the workflow would be our first priority anyway.

I have been keeping an eye on the posts here relating to non-App, browser/JS/HTTP-based WiFi setup and it seems this should also be ready shortly, and I’m assuming should also be able to use the same authentication mechanisms - this was one of the other important things we’d like supported (whilst useful and probably seen by many customers as appealing, requiring your customers to have an iOS or Android device in order to use your product is not great!).

I’m not sure if you have put any thought into this but some other platforms allow the product creator to lock down the device to only run firmware produced by the original product creator. Will this be something you will support?

Thanks Jeff.


Good point @neo12ibraheem, we should not be requiring you to have a mobile app in order to have customers and allow them to set up your devices. This would be a nice thing to roll into Particle JS, to provide you with tools to create a web-based setup process for the app. @nexxy heads up our open source toolchan.

And to your last question – yes, unless configured to be reprogrammable by the end user, the firmware will only be able to be controlled by the product creator. This will also be part of the initial setup process when configuring a product.




Thumbs up for non-app based Wi-Fi setup for the Photon.

I think this would have some advantages :

  • Customers dont need to know anything about Particle.
  • Customers dont need to install a Particle App
  • Doesnt matter who owns the core, management of SSIDs could be carried out on the cores website.
  • Dont need to know about core ids - just what devices webpages you are looking at.
  • Provides a central place to update other settings for your product - e-mail address, LED intensity etc
  • Provides security while also allowing free movement of the cores (in a classroom environment)
  • Dont have to do work for each platform (Android, Apple, Blackberry, Windows Phone etc)