Launch HN: Nango (YC W23) – Source-available unified API
Hey everyone, we are Bastien and Robin from Nango (https://www.nango.dev). We take care of the annoyances of external APIs (167 and counting) so you can quickly build custom integrations for your SaaS, while retaining full control over how they work. 2 min demo video: https://www.loom.com/share/d04c67b47e284e86b91b4b99fba548ec
SaaS engineering teams face a tough choice: they can build each integration in-house from scratch, which gives them full control but takes a lot of time and maintenance effort. Or they can use pre-built solutions, which are fast and easy but less flexible and might not fulfill all customer needs.
Nango combines the best of both worlds. We let you quickly ship custom integrations without building complex infrastructure or diving deep into the quirks of each API. You control the business logic, data models, and customer-specific configurations, like custom field mappings. We handle (O)Auth and run your integrations reliably in production.
Under the hood, your integrations run as typescript “lambdas” on Nango. A typical integration has 3-5 lambdas of 20-50 lines of code each. These lambdas live inside your git repo, are version-controlled with the rest of your app, and get deployed to Nango with a CLI (https://docs.nango.dev/understand/core-concepts).
Our runtime has a built-in scheduler for continuous background syncs, monitoring to know if your integrations run as expected, detailed logging of everything that happens in Nango, and pre-built infrastructure to deal with (O)auth, retries, rate-limit handling, webhook floods, data caching, de-duplication, etc. More here: https://docs.nango.dev/understand/architecture
We have found that ChatGPT and Copilot let you build integrations on Nango very fast without having to learn each API’s intricacies. LLMs are great at figuring out which endpoint to use, what parameters it takes, etc. Paired with our runtime, this lets you build complex, high-scale integrations in hours instead of weeks.
We’ve put a ton of effort into dealing with API complexities, so you don’t have to. Even integrations that looked simple at first ended up forcing us to extend our infra to deal with their quirks and gotchas.
For example, we had to figure out 100+ different OAuth implementations (see https://www.nango.dev/blog/why-is-oauth-still-hard and https://news.ycombinator.com/item?id=35713518). We had to deal with a half-dozen non-standard auth methods (Github apps, Stripe apps, Netsuite, etc.), expiring webhooks, ways to deal with data dependencies, weird pagination methods, API keys that change with every API call, dozens of different ways to register for webhooks, etc. It’s a constantly moving target, but it is a challenge we have come to love, and we think the approach makes sense: we specialize in finicky details that vary from API to API—you specialize in making your product great and offering more integrations to your users.
Last but not least, Nango is open source (https://github.com/NangoHQ/nango) under the ELv2 license (allows most use cases, except for direct copy-cats). Anybody can contribute new APIs & share their integration templates with the community.
The fastest way to see Nango in action is with our interactive demo here (no signup required): https://app.nango.dev/hn-demo
Or take a look at our docs: https://docs.nango.dev
We would love to hear your feedback and look forward to the comments!
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?
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).
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).
Nice idea.
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?
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?
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.
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!
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
Yes, this is correct!
So you're basically trying to remove the need for Zapier as a bridge between different SaaS products?
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)
- 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!
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
Consider putting a screenshot at the top of the README. Even one you already have, like this one:
https://docs.rollout.com/overview/what-does-rollout-provide
Thanks for the feedback - just added one!
Do you leverage Gorilla (https://gorilla.cs.berkeley.edu/) at all? If not, perhaps consider if it would solve some pain for you.
https://news.ycombinator.com/item?id=36073241
you mean add pain by introducing a nondeterministic LLM in the loop where none is needed?
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.
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)
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.
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.
[1] https://medium.com/@rgranadosd/using-ai-to-build-our-apis-wi...
[2] https://docs.sentry.io/product/issues/issue-details/ai-sugge...
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
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.
Congrats on the launch Bastien and Robin!
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
Yes, this works, and it's a feature we offer for free!
Beautiful! Thanks for taking the time to reply!
We will be looking to self-host: I’ll start going through your docs, thanks again!
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).
What is the effect of the license in this case? I find the Elastic license hard to parse to be honest.
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?
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.
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?
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.
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!
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.
Thank you for the insights and looking forward to chatting!
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.
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.
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
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
This is really great work, I will try it out. How do I reach out if I have questions?
We are very active on the Slack community: https://nango.dev/slack
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).
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
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.
Good luck with the launch! Looks awesome. I will take a deep look into integrations to use on my SaaS.
This is going to be crucial infrastructure for the next generation of LLM applications
As the LLM's need to talk to various API's ?
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!
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?
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!
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...
How does the "scale plan" work and how much is it?
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 ?
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?
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
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.
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.
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?
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.
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!
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?
Quite similar to make.com and similar products right? Any differentiators from them?
Congrats on the launch! This is such an important space for disruption.
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.
This is not open source.
Obligatory mention of ELv2 not being open source (not OSI approved!).
Congrats
> 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
I don't think it's in anybody's interest to rehash this again, so have put "source-available" in the title above.
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.
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.
[dead]
[dead]
Good work! But ELv2 != open source. Clickbait destroys trust.
We changed the title: https://news.ycombinator.com/item?id=40159204
[flagged]
*Limitations*
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.
This is https://cloud-elements.com/ all over again