IFTTT integration using two legged authentication


Hey Team, couldn’t be more excited to see the updated product creation documentation talk about authentication modes… We are building an IOT product using Particle and have two core scenarios to cater to:

  • User must be able to share access to our product with other users (family and friends)
  • Leverage the IFTTT channel to harness automation capabilities

Now we are trying to figure out the authentication scheme, which supports both of these scenarios. Looks like the two legged authentication where customers are aware of only the account they create for our product and we create a Particle account behind the scenes, Seems like what we want.

This way we can manage the access and sharing of the device at our own layer and assign an accesstoken to talk with Particle, but it is not clear how IFTTT would work in that scenario since they aren’t aware of the Particle account… Do we have to share the. particle credentials with them to make it work?

Any insight would be appreciated here…


Hi @krazineurons,

Ooh, good question! IFTTT lets you set your oauth authorization urls separate from your API url, so I think in this case you could have your channel/users auth against your API, and have your auth API return a Particle user token. From there IFTTT could leverage our api directly using that token.



Thanks for the response @Dave ! I should have clarified, we don’t have an IFTTT channel but would like our users to use Particle’s IFTTT channel but through the account they created on our site. In the particle firmware we are adding support to call our API when a particular method is invoked via IFTTT, thus getting around the need to have our own IFTTT channel…

is that feasible? are we thinking it the wrong way?


Hi @krazineurons,

Hmm, if you’re using our literal IFTTT channel, then your users would need to use the default IFTTT auth path. However we do have an IFTTT Channel Api, to make it extremely easy to create your own IFTTT channel, which I think will make it much easier. :slight_smile:



ooh an IFTTT channel API!Thanks @Dave that sounds godsent! where can I find instructions for it? did I miss it in the documentation?


Is there any updates regarding IFTTT channel API?

In two legged authentication, only customer’s email is registered on Particle & No password required, on behalf of my organization and our org get access_token of customer from Particle. If customers want to use Particle IFTTT channel, then how can they use, as they’re not registered directly on Particle and they’ve no password to sign in directly to Particle account?

@Dave @wgbartley Pls try to clear the problem :blush:


Hi @mohitagnihotri,

We do have an IFTTT Api Api, happy to share notes on that. If you’re not using our customer / user authentication system, then you’ll need to perform authentication against your API, which means IFTTT will be pointed at you and not at us. You could setup a proxy API in this case, and let your server do the auth, and pass the device requests to us using your main access_token. Or you could create shadow customer accounts and use those accounts while hitting us for IFTTT requests.

Happy to share details on our IFTTT Api Api if you’re at that stage.



As I’ve implemented two legged authentication and now I’m ready to implement IFTTT Api Api. Please share the details.

Thank you!


Hi @mohitagnihotri,

Sure thing! I’ll dig up / write up the documentation. It’s only used by a few community members since getting an IFTTT Channel can be tough, so it might take me a day or so to find. :confused: Sorry about the delay!



No Problem @Dave, I can wait :smile:

It will be great thing for my customers if I implement this.
Thank you so much!


Hi @Dave,

Its more than 1 month. Is there any update on this? I’m eagerly following this topic since Apr 5.


Hi @mohitagnihotri,

Sorry about the wait, I haven’t had a chance to work on this, we’ve been really busy preparing for Maker Faire. I’ll try not to keep you waiting much longer.



Okay Dave! I can understand. Thanks.



We’re also on two-legged auth, so I’d also love the API info.

However, I really doubt that we’ll get our own IFTTT channel anytime soon. So I was hoping that in the interim we could post IFTTT recipes that use Particle’s channel. The issue is that a customer can only subscribe to the Particle Channel with username/password credentials. If you allowed a token-only subscription to the Particle Channel we could make things work. i.e.

  1. Our Customer learns they can use IFTTT recipes with their Particle powered product.
  2. We generate a never-expiring Particle token, scoped to this Customer from our server.
  3. Customer subscribes to the Particle channel using this token.
  4. Customer adds our recipe to their account.
  5. If ever customer feels the token has been compromised, or want to leave IFTTT, they simply request we delete the token.

This means the Customer couldn’t do this if they also wanted to use their own Particle account… but in our case there is really no overlap in client demographics. So I can’t imagine it being an issue.


Hmm, so in this scenario we’d extend the oauth login window to allow providing an access_token directly? If you’re generating a token for them, would it be a stretch to provide them customer username/password credentials to login to IFTTT with?


Can I do that with two legged Auth? We’re creating Customers with no password… I suppose we could create them with a password?


Hi @mebrunet,

That would allow you to be up and running quickly, otherwise it’ll probably take us at least a few sprints before we could make that option available on the oauth login page.



Any update on this @Dave ?


Hi @mohitagnihotri,

Sorry I don’t have any updates on this yet. I handed that project off to @bryce, lets ping him and give him some time to respond, I know they’re pretty busy today.



@Dave @bryce It has been long time. Any updates?

Actually, I want to give IFTTT function to my customers next month.

It is the screenshot of my product dashboard screen. Only IFTTT integration is missing.