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!
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)
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? 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!
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
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).
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.
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
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.
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?
1. So is this managing tokens ?
2. These templates are used instead of api's ?
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.
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