Show HN: Nango – Open unified API for product integrations (nango.dev)

Wouldn't it be easier to share the work of updating the integration code when the API evolves?

Use it as a starting point, don't blindly update, fork if necessary, periodically reconcile with upstream in order to keep up with API changes.

If you have a stable global long-term API key for a global API that you use without regards to your users' tenancy on that platform, then absolutely - just put it in your 12-factor env or other secret storage, and start developing!

But if, for every integrated service, you need to build out a custom URL to receive OAuth tokens after an authorization flow, and a database to securely store them, and a reliable background task to periodically refresh them... then you're doing a ton of work before you can even access a Salesforce or Quickbooks object on behalf of your clients. Having a service that can orchestrate all of this can make it as easy to work with as a stable API key, and then you just need to do the work.

(Nango co-founder here) We help teams who don't have the resources or expertise to build & maintain integrations. Sometimes, they need to build a lot, complex or scalable ones, or they want to invest their energy elsewhere.

Building integrations comes with specific challenges (security, ETL, etc.), which are usually not the core competency of SaaS teams.

We often see that problems related to building integrations are underestimated and can spiral in terms of engineering costs. Authorization in itself is complex, data synchronization even more so!

Speed to market.

Things don’t need to work that well to be sold. One of my employers has entire integrations that don’t work and we still sell them to the business types successfully. They then file a bug ticket and wait months until we get to it, them paying fees all the way.

You want to outsource so you can focus on building your product instead of integrations which are costly to build and maintain. Also it’s not easy to come up with these universal mappings, why reinvent the wheel? It’s unlikely that your integrations are differentiating but it is likely they enable you to close deals.

Thank you!

I agree that getting approved to have an OAuth app is a major pain point (for some APIs). We help customers navigate this and would like to do more in the future (partner with API providers, offer sandbox accounts without approval, and even manage the approvals for customers when possible).

(Nango co-founder here) Because there will be a lot less that you need to build. You will write less code & ship faster. You will get reporting, monitoring, alerting, a management dashboard & APIs. You will also have an integration architecture that scales to many complex integrations as your company grows!

If it's like https://www.merge.dev/ (another "Unified API") then the idea is they provide an abstraction layer to the other API. You build against one generic spec for a given entity ("Person", "Company", "Ticket", etc), hook up to the API, and whatever platform-specific model is squished into that generic model. You end up with only one integration to cover all instances of "CRM systems" or whatnot. Obviously you also have some vendor lock-in, but it is less work than building multiple integrations for each new $product on the market.

    https://getweather.com/api?city=berlin

    https://universalapi.com/getweather_com/api?city=berlin

    noaa.com/api?city=berlin

    foreca.com/api?city=berlin

    darksky.com/api?city=berlin

    getweather.com/api?city=berlin

I don't know anything about Nango, but I guess you get DropBox, OneDrive, Drive and others with a single normalized interface. I can definitely see the benefits of such an abstraction, but I'd like to be able to self-host and wouldn't use a cloud.

Your example is very simplified and not what real integrations look like.

I'm working on a feature using a different, but basically the same type of service (APIDeck), and for us we're using it cause our customers want 3rd party integrations with Shopify, Hubspot, Pipedrive etc.

Rather than have a trillion different custom implementations for each 3rd party service (prone to frequent breaking), we just call the unified APIDeck endpoints for everything. We get the same exact data structure regardless of integration, so all the code is super generic and crazy easy to work with.

Whatever platforms they support, we support, and all we have to do is toggle a button, after which the integrations page gets populated with each activated integration. They bother with the actual integrations and making sure they're up-to-date with whatever changes all the different platforms make, and it's so much better than what we had before where we had to upkeep 30(!!!!) different integrations, all with various API patterns & return types and whatnot.

Our usecase is that we have a sidebar where we embed the contents from various CRM and Ecom apps, so a user "installs" an integration through APIDeck (skinned to look like our own thing), and then we just fetch through APIDeck and display whatever it gives us back to the user.

(Nango co-founder here) We use the Elastic license precisely for the reason you mention: to prevent companies from rebranding Nango and selling it as it is. For all other use cases, it should be accessible.

(Nango co-founder here) Codat is focused on financial integrations, and Nango is transversal, so you can have all your integrations on one platform.

(Nango co-founder here) That's a great point. You highlight a key limitation of traditional unified APIs and one of the reasons why we started Nango.

There's a lot of subjectivity that goes into unifying functionalities across APIs. Traditional unified APIs must make these subjective decisions for all their customers in a one-size-fits-all manner.

Nango lets you customize integrations & schemas, so you can make these subjective decisions for yourself. The result is a unified API that truly fits your business use case.

Still, some radically diverging API functionalities cannot be unified, which requires some additional API-specific logic to handle. This can be abstracted in our integration scripts, supported by our tooling, instead of living in your main code-base.

(Nango co-founder here) Great. The client is just a thin wrapper around our REST API, which can be called from any language. But we plan to release SDKs for all main languages this quarter (including Java). Happy to chat on the community!

(Nango co-founder here) I'll update the repo readme and other mentions of being open source. Thank you for reporting this. We are not set on the license yet. We want to promote permissive usage, particularly for the auth-related features & contributed integration templates, but we are being mindful of the competitive environment.

This looks very interesting, congrats! Do you support write-backs & workflows?