This looks very interesting, but I have two questions.
1) Did I understand this correctly, oversimplifying, instead of going api.slack.com/users I go nango.com/slack/users
If I did it leads to question 2) since I assume this won't have feature parity 100% of the times, what's my escape hatch when I need a feature that's available in an api and not in your service, if worse comes to worse, can I still easily access the original api easily?
bastienbeurier 135 days ago [-]
1) That's right!
2) You can write your own integration scripts, in code, consuming any endpoint from the external API, so you are not limited to what Nango pre-builds (details: https://docs.nango.dev/understand/concepts/scripts).
1) Nango supplies easier-use-to-use wrappers over a host of common APIs, making the most common operations simpler. Nango generally handles auth, logging, pagination.
2) Nango is extensible through custom scripts when your use case falls outside the common ones.
Question 1) Nango provides some consistency to the APIs in its wrapper so, to some extent, you are learning the "nango way" vs hundreds of bespoke ways?
Question 2) How do you handle API churn with hundreds of APIs supported? On any given day, there's got to be a decent chance of something changing that breaks you?
rahimnathwani 135 days ago [-]
I read your entire post, and couldn't understand what you do.
After watching the video, I think you make it easy for SaaS creators to give their customers the ability to integrate with other SaaS/API products. Is that right?
So e.g. if I make a SaaS tool for plumbers, and some of those plumbers use Xero for accounting, then I could use Nango to allow those plumbers to set up some data flow between my SaaS and Xero. Right?
spxneo 135 days ago [-]
im also not clear/sold on the value proposition or perhaps im misunderstanding things but
How does Nango differ from existing solutions? Seems like everybody is working on on programmatic "Zapier" (if thats what this is?) with OpenAI wrapper thrown over it.
rahimnathwani 135 days ago [-]
I think the point is that your customers don't need to use Zapier, as you can give them something that's simpler to use, right inside your product.
I might be wrong. I have the same info you do!
wouldbecouldbe 135 days ago [-]
Yeah so idea is you can easily integrate with lots of bookkeeping software with just one api. A zapier integration is often also not ideal or existing and a pain to set up for users
rguldener 135 days ago [-]
Yes, this is correct!
rahimnathwani 135 days ago [-]
So you're basically trying to remove the need for Zapier as a bridge between different SaaS products?
rguldener 135 days ago [-]
I think there will always be a use case for Zapier to cover the very long tail of integrations.
But we want to make it easier for engineers to offer their customers the native integrations they need.
Usually, these cover the most important and most valuable use cases. But they are often also the most complex to build (e.g. reliable 2-way data syncs)
rahimnathwani 135 days ago [-]
I think there will always be a use case for Zapier to cover the very long tail of integrations. But we want to make it easier for engineers to offer their customers the native integrations they need.
This is a better description of your product than what you wrote in your original post. Maybe worth iterating to see what resonates with your target audience.
e.g. reliable 2-way data syncs
I'm curious about this. Can you give a real-life example of a 2-way data sync you or your users have set up?
rguldener 135 days ago [-]
Can you give a real-life example of a 2-way data sync you or your users have set up?
Sure:
- A support SaaS uses Nango to sync contacts & companies with CRMs (Salesforce, HubSpot, etc.)
- A billing SaaS uses Nango to sync invoices, customers, etc. with accounting systems (Quickbooks, Netsuite, etc.)
- A security-focused SaaS uses Nango to create issues in Jira, Linear, etc., and then syncs the status & other properties between these apps and its own product
I hope this helps!
alalani1 135 days ago [-]
If Zapier is your mental model, the use case there is trigger/action workflows which is a different from 2-way sync which I'd say Nango does well. For the former you might want to check out this open-source project I work on: https://github.com/RolloutHQ/rollout
rahimnathwani 135 days ago [-]
Consider putting a screenshot at the top of the README. Even one you already have, like this one:
We’re currently planning on integrating with many oauth-based apps where our end goal is to provide always valid access tokens to end customers (developers), abstracting away the complex refresh mechanism that we take care of.
Is it something we could do with Nando?
The simplified flow looks as follows:
1. Customer logins via oauth in a dedicated portal
2. We have a way to retrieve the access token at any time from Nando via an API
3. We handover that access token to our user for their own calls to the oauth-authenticated APIs
bastienbeurier 135 days ago [-]
Yes, this works, and it's a feature we offer for free!
nip 135 days ago [-]
Beautiful! Thanks for taking the time to reply!
We will be looking to self-host: I’ll start going through your docs, thanks again!
lordofmoria 135 days ago [-]
Congrats! We’ve been using Nango for about a year, mostly to handle oauth flows for us to about 7-8 integrations (Dropbox, google drive, etc) that our users can self-service connect in our app.
Very stable, the team is respnsibe to handling the weird corner cases (which their value prop is all about), and they seem to be able to build new integrations and functionality quickly.
I’ll be taking a closer look at their sync functionality, since our users want email in app (CRM style).
anonzzzies 135 days ago [-]
What is the effect of the license in this case? I find the Elastic license hard to parse to be honest.
toomuchtodo 135 days ago [-]
Do you leverage Gorilla (https://gorilla.cs.berkeley.edu/) at all? If not, perhaps consider if it would solve some pain for you.
you mean add pain by introducing a nondeterministic LLM in the loop where none is needed?
toomuchtodo 135 days ago [-]
Unreasonable pessimism considering state of the art velocity. Determinism, while a challenge to solve for, is not entirely impossible. There is value even if you're using an LLM to code assist with integration builds (using OpenAPI specs) or breakage when an API changes suddenly.
(contributed for several years at a low code/no code prodcut org, familiar with integration maintenance and what integrating with APIs at scale looks like)
spxneo 135 days ago [-]
I don't think parent is being unreasonable if my perception of Gorilla is correct here but
Lot of mission critical apps cannot risk even 0.01% chance of hallucination or some blackbox process
Like I don't think a direct LLM-2-API is feasible for even enterprise clients unless LLM generates that 2-API code layer that can be audited but right away that negates the need for Gorilla
Seems like "just trust this blackbox because everybody is writing wrappers around it" is similar to "throwing redux because facebook said so" 7 years ago. Definitely seeing some parallels with technological pollyannaism with blockchain.
toomuchtodo 135 days ago [-]
I agree you cannot trust unsupervised LLM output for mission critical M2M use cases, but (imho) it will help you move faster to create and maintain integrations with human supervision (code->SVN->test harness part of CICD->human review [1] and editing + proposed fixes for failure detection via Sentry [2] or similar). My apologies I did not make that more clear further up subthread.
To determine if this creates a positive value creation trajectory, some implementation and caretaking of the code generation pipeline is necessary.
I'd call it realistic. It's one thing to have an LLM developer facing and suggesting improvements etc _maybe_ "something went wrong? Try auto fix"
But LLM in a hotspot is asking for trouble in present LLM sota
swyx 135 days ago [-]
doing what i do with latent.space and ai.engineer, it was nice for someone to call me pessimistic about ai for once haha. i enjoy that on HN usernames are so de-emphasized.
135 days ago [-]
baetylus 135 days ago [-]
Love this idea - a huge pain point for many teams. I've had this issue, and am looking forward to trying this out.
I know there are a couple competitors too. How do you distinguish yourself from something like Merge.dev?
bastienbeurier 135 days ago [-]
The main difference is that Merge pre-builds all integrations, with limited customization capabilities, while Nango gives you full control over the code of the integrations.
msukmanowsky 135 days ago [-]
Not trying to be snarky, but I'm not sure why this matters? Isn't the main value prop of a service like nango or Merge just the unified API and features around it (e.g. unified webhooks for events etc)? Can you help me understand why this is important?
bastienbeurier 135 days ago [-]
Standard pre-built integrations are ok to get started. But rapidly customers ask for more integration capabilities, which are not supported by standard integrations. At this point, SaaS companies need to build custom integrations that fit exactly what they customers want.
dominicwhyte 135 days ago [-]
Nango is awesome. I've used it across several projects and it's sped up our "time to live integration" significantly + reduced maintenance costs. Congrats Bastien, Robin and team!
alertify 135 days ago [-]
At https://bot9.ai (most advanced AI based Customer service engine) we are currently building integrations for CRMs, Ticketing tools, Chat softwares, Ecommerce platforms etc which the bot connects to.
For example the bot connects to freshdesk or intercom and handles the tickets / chats just like a normal agent, and handsover to a human if it can't solve or a customer asks, without the company having to change their chat or ticket tools.
Or connects to shopify to help customers answer any pre-sales questions or help them make a purchase decision.
I see the pain in building these integration one by one and currently exploring a few SaaS that will help me have lot more integrations without us having to build & test one by one (Months).
Paragon , hotglue for example.
There are generally two approaches to do this, each with their pros and cons.
A few go with a unified api approach.
The benefit is that you can integrate one Unified CRM API and then use all CRM softwares directly.
While this does give a lot of headstart, the downside is that all CRM or ticket softwars may not have the same terminology and you may get into problems.
For example, intercom does not really have a ticket type system but still people use it for ticketing. Whlie freshdesk or Zendesk is a proper ticket system with lots of variables that can be mapped to a ticket.
With a unified API you kind of lose out on max potential of the platform you are integrating with, at the cost of faster integration.
Then there are direct APIs which still allow faster integration by handling auth, logging, debugging and some kind of unification but you have to still integrate them one by one in your SaaS.
So you gain lot more control, at the expense of time to implement.
By looking at the docs, I see they are trying to go with a hybrid model where they give a direct integration option but i can map the models myself which kind of covers both cases ? Someone from the team can comment. But Interesting.
This is definitely an interesting space which has been mostly covered by zapier. but zaps are ugly, a glue and very expensive for anything serios and mostly used by individuals who just want to connect a few systems together.
In this AI era where everyone is building something with AI and finding out that building the MVP is pretty easy but then gets stuck on expanding because customers wants things to work inside the tools they already use, there is definitely a market for this.
I have sent a meeting request, happy to connect and see if this helps us.
bastienbeurier 135 days ago [-]
Thank you for the insights and looking forward to chatting!
xgb84j 135 days ago [-]
One challenge I encountered in the past was syncing data between a SaaS software I built and customers' ERP systems. Building these integrations was an absolute pain because there often is no publicly available documentation. This means you need to pay an SAP consultant 300 dollars per hour to tell you all the things normal apis have in their public documentation. Is this something you plan to address? Or are you just making already usable apis even easier to use?
Btw great product! Just really curious about a personal pain point of mine!
bastienbeurier 135 days ago [-]
We've noticed the same pain point and we are providing increasingly better support for ERPs. Realistically, it takes time to build expertise on each of them, but we'll get there!
ensemblehq 135 days ago [-]
Would be great if the Nango team can address it but my experience as that "300 dollars per hour" consultant (although I never got to see anywhere close to that) is that most ERP systems are heavily customized that it would be hard to auto-generate endpoints/documentation off of it.
Have you had a chance to go through your customers' ERP systems?
ultrasaurus 135 days ago [-]
I love giving users a library of lambdas. We did something similar almost a decade ago at PagerDuty, we'll map the fields & headers for you and provide examples, but you can munge up the json however you want: https://www.pagerduty.com/docs/guides/custom-event-transform...
brap 135 days ago [-]
I spent about 5 minutes (incl watching the demo) and I still don’t quite understand what this does.
I’m probably not in your target audience, so maybe the issue is with me. But I think you should consider clarifying the use-case and value a bit.
It’s one of those things that should probably be immediately obvious to anyone working on SaaS. I was curious so I spent some time on it, potential customers may not be as forgiving and might give you just 10-20 seconds.
stuartjohnson12 135 days ago [-]
I'm in the target audience and still don't fully understand, although I do think the market needs more tools like this.
Generally speaking, the value prop for tools in this space tends to be that they map similar data concepts from lots of providers into one API so that it's faster to build interoperability. For example, if you're shipping a project management tools integration, every tool has the equivalent of a ticket and a project and a label regardless of what they call it.
What I /think/ this tool does is go one layer further and provide cloud-based orchestration for chained integration calls with appropriate failover and observability hooks built in automatically. Which is a sensible tool I think the market is hurting for.
But I could be wrong, and that's concerning.
conqrr 135 days ago [-]
Their front page is quite clear. Haven't seen the demo though. Its a unified API for all Integrations that your Saas can have. Typical Saas has integrations with a lot of other Saas and its like a web of complexity that you have to build from scratch. With Unified API you integrate with one API and it can give you things like auth, data, syncing from Github, twitter, Google, etc
spxneo 135 days ago [-]
Doesn't that already exist? I'm also not sure what the edge/value proposition is.
If I need API integration done, there are already MIT licensed programmatic solutions that I can self host on AWS
callmeed 135 days ago [-]
It's interesting, seems like a popular space lately (even within YC). Off the top of my head, there's merge.dev, Terra, Kombo, Workato.
Aside from the obvious question of "how are you different/better?" I'm most curious to know why you're going so broad initially. You've got everything from legal to devtools to gaming. Seems like the opposite of a wedge/beachhead approach. Why?
dominicwhyte 135 days ago [-]
We evaluated most of these (minus Workato) and landed on Nango. Was by far the most flexible and having the source code available was a big plus (vs. the closed-source alternatives). The team is also reactive to feedback in their Slack community, they even added a few new endpoints for us in < 24 hours
bastienbeurier 135 days ago [-]
The players you mentioned pre-build standard integrations, in specific categories (e.g. HRIS). We build a platform that lets developers build custom integrations, for any API.
We do offer integration "templates", but it's only a way to get started and templates are meant to be extended.
That's also why our catalog of APIs is extensive. Anybody can rapidly add support for any new API and start building custom integrations for it, and share templates with the community.
nextworddev 135 days ago [-]
This is really great work, I will try it out. How do I reach out if I have questions?
I'm struggling a bit to figure out the pricing here. If I have lets say 50 users that sync Trello, does that count as 50 synced connections?
bastienbeurier 135 days ago [-]
Some integrations are connected at the org level (one account for the entire company), and others at the user level (many accounts per company). For the latter case, the pricing per connection is lower.
sqs 135 days ago [-]
Very cool idea! I got rejected from Y Combinator in 2006 for a similar idea. Still surprised nobody has done this. Congrats on the launch!
harrylucas 135 days ago [-]
Wanted to check if this actually provides a unified api? E.g. each category of integration will return the exact same data shape? From the looks of the video I'm still making a call to slack's API `users.list` and have to write the code to paginate slacks api (e.g. the next cursor).
alalani1 135 days ago [-]
I think its easier to market "unified API". In practice, it is more like an API to call another API with some niceties like Auth handled + retries
bastienbeurier 135 days ago [-]
It does!
Because Nango lets you define input & output models of integrations, it's easy to standardize them across APIs.
So, when syncing users from Slack/Discord/Teams, you define a standard User model, and all 3 integrations map to this model.
You then consume User objects from a unified endpoint, regardless of where they come from.
rumad 135 days ago [-]
Good luck with the launch! Looks awesome. I will take a deep look into integrations to use on my SaaS.
mnafees 134 days ago [-]
Congratulations on the launch! I am interested to know the choice of runtime (in this case - TypeScript) for the implementation of the integrations. What are some reasons that a systems language such as Go was not chosen?
digitcatphd 135 days ago [-]
This is going to be crucial infrastructure for the next generation of LLM applications
Vishnu3014 135 days ago [-]
As the LLM's need to talk to various API's ?
angryasian 135 days ago [-]
I'm a little confused. Doesn't the user still have to sign into each oauth service individually still ?
1. So is this managing tokens ?
2. These templates are used instead of api's ?
exolab 135 days ago [-]
How does the "scale plan" work and how much is it?
azuby 135 days ago [-]
Nango has been a pleasure for us to work with. We're not affiliated in any way, we're just a happy customer and highly recommend it.
prakhar897 135 days ago [-]
Quite similar to make.com and similar products right? Any differentiators from them?
sgammon 135 days ago [-]
Congrats on the launch! This is such an important space for disruption.
duggan 135 days ago [-]
Love the source available API proxy, that’s a useful component on its own! A little disappointed to see that most of the really good stuff is not available for self-hosting, but an IPaaS/Unified API is a not the kind of project one tinkers away at on the weekends for the joy of it. It’s hard work, deserves congratulations, and bills gotta get paid.
I remain ever hopeful for an open source IPaaS some day (had a chat with my cofounders about it this morning actually) but I just don’t see the incentives aligning. 1.) It’s hard to do, 2.) I don’t see a megacorp sponsoring a CNCF project, 3.) some amount of the work is in mapping concepts to your own platform, 4.) there is a gauntlet of legal agreements, branding guidelines, security reviews, etc., to go through with third parties regardless.
All that said, I'll be taking a closer look at Nango, because this is an evergreen problem, and I'm interested in finding the best solution.
icy 135 days ago [-]
Obligatory mention of ELv2 not being open source (not OSI approved!).
JonAtkinson 135 days ago [-]
This is not open source.
rokgregoric 135 days ago [-]
Congrats
mdaniel 135 days ago [-]
> open source ... under the ELv2 license
I would think a Launch HN would know better than to use "open source" with a non open source license. It is source available, sure, and it's your software so you can license it as you wish, but don't call it open source as that continues to pollute the very idea of the software freedoms that actual open source licenses are designed to provide
andy99 135 days ago [-]
I actually clicked to commend them on being open that it's "source available" but I see now that was an edit. Seems like a good strategy is just to embrace the source available label, people either don't see the distinction or they're like you and me that will come and complain if someone uses "open source" incorrectly.
dang 135 days ago [-]
I don't think it's in anybody's interest to rehash this again, so have put "source-available" in the title above.
infrawhispers 135 days ago [-]
ELv2 is not an open source license. Why are so many companies using “open source” to scaffold on traction and interest? This framing is disingenuous.
chigup36 134 days ago [-]
[dead]
chigup36 134 days ago [-]
[dead]
frozenmaestro 135 days ago [-]
Good work!
But ELv2 != open source.
Clickbait destroys trust.
You may not provide the software to third parties as a hosted or managed service, where the service provides users with access to any substantial set of the features or functionality of the software.
You may not move, change, disable, or circumvent the license key functionality in the software, and you may not remove or obscure any functionality in the software that is protected by the license key.
You may not alter, remove, or obscure any licensing, copyright, or other notices of the licensor in the software. Any use of the licensor’s trademarks is subject to applicable law.
1) Did I understand this correctly, oversimplifying, instead of going api.slack.com/users I go nango.com/slack/users
If I did it leads to question 2) since I assume this won't have feature parity 100% of the times, what's my escape hatch when I need a feature that's available in an api and not in your service, if worse comes to worse, can I still easily access the original api easily?
2) You can write your own integration scripts, in code, consuming any endpoint from the external API, so you are not limited to what Nango pre-builds (details: https://docs.nango.dev/understand/concepts/scripts).
But you can also access the original API through the proxy, which will inject credentials, log requests, help you with pagination (details: https://docs.nango.dev/understand/concepts/proxy).
So to recap:
1) Nango supplies easier-use-to-use wrappers over a host of common APIs, making the most common operations simpler. Nango generally handles auth, logging, pagination.
2) Nango is extensible through custom scripts when your use case falls outside the common ones.
Question 1) Nango provides some consistency to the APIs in its wrapper so, to some extent, you are learning the "nango way" vs hundreds of bespoke ways?
Question 2) How do you handle API churn with hundreds of APIs supported? On any given day, there's got to be a decent chance of something changing that breaks you?
After watching the video, I think you make it easy for SaaS creators to give their customers the ability to integrate with other SaaS/API products. Is that right?
So e.g. if I make a SaaS tool for plumbers, and some of those plumbers use Xero for accounting, then I could use Nango to allow those plumbers to set up some data flow between my SaaS and Xero. Right?
How does Nango differ from existing solutions? Seems like everybody is working on on programmatic "Zapier" (if thats what this is?) with OpenAI wrapper thrown over it.
I might be wrong. I have the same info you do!
But we want to make it easier for engineers to offer their customers the native integrations they need.
Usually, these cover the most important and most valuable use cases. But they are often also the most complex to build (e.g. reliable 2-way data syncs)
- A support SaaS uses Nango to sync contacts & companies with CRMs (Salesforce, HubSpot, etc.)
- A billing SaaS uses Nango to sync invoices, customers, etc. with accounting systems (Quickbooks, Netsuite, etc.)
- A security-focused SaaS uses Nango to create issues in Jira, Linear, etc., and then syncs the status & other properties between these apps and its own product
I hope this helps!
https://docs.rollout.com/overview/what-does-rollout-provide
This launch couldn’t be more timely for us:
We’re currently planning on integrating with many oauth-based apps where our end goal is to provide always valid access tokens to end customers (developers), abstracting away the complex refresh mechanism that we take care of.
Is it something we could do with Nando?
The simplified flow looks as follows:
1. Customer logins via oauth in a dedicated portal
2. We have a way to retrieve the access token at any time from Nando via an API
3. We handover that access token to our user for their own calls to the oauth-authenticated APIs
We will be looking to self-host: I’ll start going through your docs, thanks again!
Very stable, the team is respnsibe to handling the weird corner cases (which their value prop is all about), and they seem to be able to build new integrations and functionality quickly.
I’ll be taking a closer look at their sync functionality, since our users want email in app (CRM style).
https://news.ycombinator.com/item?id=36073241
https://news.ycombinator.com/item?id=35631555
(contributed for several years at a low code/no code prodcut org, familiar with integration maintenance and what integrating with APIs at scale looks like)
Lot of mission critical apps cannot risk even 0.01% chance of hallucination or some blackbox process
Like I don't think a direct LLM-2-API is feasible for even enterprise clients unless LLM generates that 2-API code layer that can be audited but right away that negates the need for Gorilla
Seems like "just trust this blackbox because everybody is writing wrappers around it" is similar to "throwing redux because facebook said so" 7 years ago. Definitely seeing some parallels with technological pollyannaism with blockchain.
To determine if this creates a positive value creation trajectory, some implementation and caretaking of the code generation pipeline is necessary.
[1] https://medium.com/@rgranadosd/using-ai-to-build-our-apis-wi...
[2] https://docs.sentry.io/product/issues/issue-details/ai-sugge...
But LLM in a hotspot is asking for trouble in present LLM sota
I know there are a couple competitors too. How do you distinguish yourself from something like Merge.dev?
For example the bot connects to freshdesk or intercom and handles the tickets / chats just like a normal agent, and handsover to a human if it can't solve or a customer asks, without the company having to change their chat or ticket tools.
Or connects to shopify to help customers answer any pre-sales questions or help them make a purchase decision.
I see the pain in building these integration one by one and currently exploring a few SaaS that will help me have lot more integrations without us having to build & test one by one (Months).
Paragon , hotglue for example.
There are generally two approaches to do this, each with their pros and cons.
A few go with a unified api approach. The benefit is that you can integrate one Unified CRM API and then use all CRM softwares directly. While this does give a lot of headstart, the downside is that all CRM or ticket softwars may not have the same terminology and you may get into problems.
For example, intercom does not really have a ticket type system but still people use it for ticketing. Whlie freshdesk or Zendesk is a proper ticket system with lots of variables that can be mapped to a ticket. With a unified API you kind of lose out on max potential of the platform you are integrating with, at the cost of faster integration.
Then there are direct APIs which still allow faster integration by handling auth, logging, debugging and some kind of unification but you have to still integrate them one by one in your SaaS. So you gain lot more control, at the expense of time to implement.
By looking at the docs, I see they are trying to go with a hybrid model where they give a direct integration option but i can map the models myself which kind of covers both cases ? Someone from the team can comment. But Interesting.
This is definitely an interesting space which has been mostly covered by zapier. but zaps are ugly, a glue and very expensive for anything serios and mostly used by individuals who just want to connect a few systems together.
In this AI era where everyone is building something with AI and finding out that building the MVP is pretty easy but then gets stuck on expanding because customers wants things to work inside the tools they already use, there is definitely a market for this.
I have sent a meeting request, happy to connect and see if this helps us.
Btw great product! Just really curious about a personal pain point of mine!
Have you had a chance to go through your customers' ERP systems?
I’m probably not in your target audience, so maybe the issue is with me. But I think you should consider clarifying the use-case and value a bit.
It’s one of those things that should probably be immediately obvious to anyone working on SaaS. I was curious so I spent some time on it, potential customers may not be as forgiving and might give you just 10-20 seconds.
Generally speaking, the value prop for tools in this space tends to be that they map similar data concepts from lots of providers into one API so that it's faster to build interoperability. For example, if you're shipping a project management tools integration, every tool has the equivalent of a ticket and a project and a label regardless of what they call it.
What I /think/ this tool does is go one layer further and provide cloud-based orchestration for chained integration calls with appropriate failover and observability hooks built in automatically. Which is a sensible tool I think the market is hurting for.
But I could be wrong, and that's concerning.
If I need API integration done, there are already MIT licensed programmatic solutions that I can self host on AWS
Aside from the obvious question of "how are you different/better?" I'm most curious to know why you're going so broad initially. You've got everything from legal to devtools to gaming. Seems like the opposite of a wedge/beachhead approach. Why?
We do offer integration "templates", but it's only a way to get started and templates are meant to be extended.
That's also why our catalog of APIs is extensive. Anybody can rapidly add support for any new API and start building custom integrations for it, and share templates with the community.
Because Nango lets you define input & output models of integrations, it's easy to standardize them across APIs.
So, when syncing users from Slack/Discord/Teams, you define a standard User model, and all 3 integrations map to this model.
You then consume User objects from a unified endpoint, regardless of where they come from.
1. So is this managing tokens ?
2. These templates are used instead of api's ?
I remain ever hopeful for an open source IPaaS some day (had a chat with my cofounders about it this morning actually) but I just don’t see the incentives aligning. 1.) It’s hard to do, 2.) I don’t see a megacorp sponsoring a CNCF project, 3.) some amount of the work is in mapping concepts to your own platform, 4.) there is a gauntlet of legal agreements, branding guidelines, security reviews, etc., to go through with third parties regardless.
All that said, I'll be taking a closer look at Nango, because this is an evergreen problem, and I'm interested in finding the best solution.
I would think a Launch HN would know better than to use "open source" with a non open source license. It is source available, sure, and it's your software so you can license it as you wish, but don't call it open source as that continues to pollute the very idea of the software freedoms that actual open source licenses are designed to provide
You may not provide the software to third parties as a hosted or managed service, where the service provides users with access to any substantial set of the features or functionality of the software.
You may not move, change, disable, or circumvent the license key functionality in the software, and you may not remove or obscure any functionality in the software that is protected by the license key.
You may not alter, remove, or obscure any licensing, copyright, or other notices of the licensor in the software. Any use of the licensor’s trademarks is subject to applicable law.