How do I provide third-party integrations for my SaaS app?
Almost all SAAS apps provide integrations with hundreds of other services for their customers. It feels like a tedious process to be able to support so many services.
How do you guys handle this process? Is there something like a single API that can provide faster integration times with potentially thousands of services?
I also came across https://rapidapi.com, https://tray.io/solutions/embedded and a couple of other solutions in this direction.
Trending on Indie Hackers
As others have mentioned, there's Zapier, Integromat etc - they do an awesome job of connecting you to other apps.
But I think your question is about building native integrations (judging from some of your other comments). I understand the pain point here - building lots of native integrations clutters up both the UI, the code base and can feel very brittle - the moment something changes on their side it might mean your app breaks - it's a legitimate problem to consider how to scale all this gracefully.
One approach I have used in the past for this is to build a private (or public) API in my app, then turn my app into an oAuth provider. Then, for each new integration I essentially build a new (barebones) app, have it oAuth with my main app and then use the API to do whatever it needs to do.
This keeps the main app focused on its core purpose, and distributes integration responsibilities to these "helper" apps.
More reasons I like this approach:
The best solution will depend on what your integration offering looks like. I think if you intend to have only a handful of very heavy integrations (that require their own database tables, multiple screens etc) then the above approach is quite appropriate. If you need to have lots of very lightweight integrations, then maybe it's less appropriate.
Just my 2c!
Thank you Jon. Yes, I'm exploring native integrations so that the user doesn't have to configure anything in Zapier which might also require him to pay. Eg., our app is a productivity tool for freelancers, so there can be integrations with so many tools in categories like project management, accounting, marketing, etc.
So there can be potentially hundreds of tools in fairly well defined categories that can integrate with our app.
Really interesting approach to turn your app into an oauth provider. I haven't considered it because I wasn't looking at it from the perspective of other services integrating with our app. What is the fastest way to implement this? I'm currently using firebase auth for our users.
I'm actually working on a service based architecture (not microservices though), so all integrations will be their own services. It has so many advantages like you just mentioned but most importantly, it becomes much easier to distribute the work (I have a few interns, so this is the best approach for us).
I use Ruby on Rails and for Rails there is a gem called Doorkeeper which turns your app into an oAuth2 provider basically in one step! :)
https://github.com/doorkeeper-gem/doorkeeper
I'm sure there are similar plugins for other frameworks.
The other benefit I forgot to mention is that you could even go one step further and allow people to create their own oAuth keys, essentially meaning they can build integrations for you. That's probably a step too far in your scenario but it's nice to think about being able to scale out integration development to that level, where companies essentially sign up by themselves and build their own integrations while allowing account sync via oAuth.
I will caveat by saying that this is something I did with a previous startup and I am not following this architecture for my current startup Bannerbear.com. I have 4 integrations on Bannerbear and they are all of the "baked in" variety. I keep wrestling with this idea as I would like to build more integrations but I just see it becoming a tangled mess very fast - so I'm interested in other people's approaches to this too. If I don't see any better solutions in this thread then I may go ahead with turning myself into an oAuth provider as above 😅
Yeah, the oAuth keys piece is definitely a step too far away for us. As long as you can separate the integrations out into their own services, you should be able to have maintainable code with more number of integrations.
Bannerbear looks awesome btw. I remember the first version of the site you put up. Looks like you've had quite a journey... :)
All the best.
Hey check out Zapier
Thanks @vacom. Yes, I'm looking at Zapier as well. It is the first integration in our roadmap. But so many apps provide native integrations with other services. I was trying to figure out a scalable way of doing it.
Alright makes sense, doing some research to make the right decision. I never implement such a platform but when I think of this kind of apps the one that comes to my mind is Zapier.
Yes, Zapier and Integromat are the go to platforms for such things. Just trying to step it up for our users quickly if possible. Will explore further and post my findings here.
In my search for a solution, I stumbled on ipaas - kloudless, Blomi, and cyclr. Not used any yet, but got my eyes on cyclr.
Thanks @gdi. I'll check these out.
Glad to see you already have Zapier on the roadmap. In my opinion focusing on making that integration rock solid with lots of triggers and templates is a good place to invest time since it will allow you to connect with so many other services smoothly. The more individual integrations you provide the more you have to maintain and that eventually catches up and leads to spikes of unplanned work :(
Agreed. That maintenance overhead is what I'm worried about - managing rate limiting, monitoring integration uptimes, token refreshing are just a few that come to mind. I'm sure there'll be more.
One of the selling points of my product is that it can integrate easily with other services. Currently, it integrates with GitHub, Slack and Pivotal Tracker. I intend to add more when I see that there is interest from customers.
Many API:s have similar authentication schemes which can help you in creating reusable abstractions that you can use to extend your support for other services. Also, you might be able to abstract some of the implementations for features in similar services.
Thanks Adam. So if I understand this correctly, you are implementing all these integrations manually. Am I right?
Agree with you on the similar auth aspect. Many of them support oauth or API key based auth which makes it easy to create a common abstraction.
Apparently this whole space is called IPAAS (Integration Platform As A Service). Came to know recently and there are a number of service providers in this space although almost all of them seem to be expensive.
That's correct. If there are official SDKs available for the language I am using (Kotlin/JVM), I use them to save time. If not, I just use an HTTP client and create my own small SDK for the functionality I need in their API.
Compared to building the rest of my service, building these integrations is easy. As long as they have good documentation, it just requires some simple coding to hook up to their API.
Cool. Thanks @adamringhede.
Great question. We intentionally built consentry.org for existing Segment customers partially for this reason. We got access to all of Segment's partners immediately, without needing to build our own UI for integrations. We could eventually build our our own stuff, but when running lean like we are, every little bit helps. Our integration with Segment helps keep even our MVP experience magical.
Cool website. This is a very interesting strategy. I'll explore if we can do something similar.