Any time I see a "unified API" where multiple interfaces are abstracted to a single interface, my first concern is the lowest common denominator problem.

What I mean by that is your unified API can only support features that all of the APIs it is abstracting also support. Otherwise the users of that API will make calls and not know if they will work because it will depend on the backend.

The classic example of this was when people tried to create unified APIs for AWS, GCE, and Azure. They had to only support features all three had, otherwise the API would break if you used the wrong cloud provider, in which case it was easier to just interface directly with said cloud provider.

Which is a lot of words to say, how will you support multiple APIs with different feature sets without breaking your API?

(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.

I have mixed thoughts about this approach.

Unification should mean creating a single interface that seamlessly interacts with multiple underlying services without needing custom adaptations for each case.

The issue with allowing for customization is that it leads to fragmentation. This defeats the purpose of having a unified API in the first place.

I'm not sure whether the convenience of unifying leftover common functionalities like authentication outweighs the complexity and reliance introduced by adding another layer to the tech stack.

These are all fair points!

In practice, most customers we serve have use cases that could not be supported by traditional unified APIs, but are still better off not rebuilding an integration infrastructure from scratch.

We also offer professional services to outsource the customization, so you still have an off-the-shelf unified API, but specific to your company.

Back in August I queried [1] your usage of "open source" while not being an open source project (ELv2 licensed). It looks like you're no longer describing yourself as "100% Open Source" which is good but you still label yourself as open source in the repo readme and still refer to yourself as open source on the website. Do you intend to keep labelling yourself as open source or is that something you're moving away from?

[1] https://github.com/NangoHQ/nango/issues/900

(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.

Sure, I understand and respect the desire to protect your efforts. Thanks for responding and being receptive!

Nice yall - love the updates

You have built a really great product that is easy to use. I've tested out the self-hosted option on render.com with neon postgres and the cloud version. Both are super easy to get up and running.

Now, it is no exaggeration to say that the most annoying part of adding a new integration is just navigating the API provider's portal to get the app outh creds.

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).

I'm scratching my head. Why I would want to put an API in front of an API which I want to use?

So instead of

    requests.get(
        'https://some_api/some_endpoint?some_params',
        headers=some_headers
    )

I have to do

    requests.get(
        'https://some_other_api/i_want_something_from_some_api/some_other_endpoint?some_other_params',
        headers=some_other_headers
    )

?

What is the benefit of doing this?

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.

I don't understand what you mean.

Say the API is

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

What benefit do I get from calling

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

instead?

Can you show in code, what you mean?

We use Merge for an app I built so I can elaborate.

Using your example, let's say I want to get the weather for Berlin today from NOAA, Foreca, and DarSky. I would have to do:

    noaa.com/api?city=berlin

    foreca.com/api?city=berlin

    darksky.com/api?city=berlin

return each results and store them.

As opposed to sending the call once:

    getweather.com/api?city=berlin

Now let's say I want to add a new source (Wunderground). I login to Merge/Nango and just check "Wunderground" and just change my API call to store the new source.

Now let's say Foreca changes it's API to foreca.com/v2/api?city=berlin I don't have to monitor this at all. Merge/Nango would do this for me.

Regarding your first point, combining 3 API calls into one: Well, it is just one line of code on your server. But you have put the rest of the logic into the Merge/Nango server. Maybe via some point and click interface. But it is still there. So your complexity went up, not down.

Regarding your second point, APIs don't change just nilly willy from /v1/ to /v2/ and let you "fix" it by swapping "1" with "2". Usually you get changes like /v1/weather does not exist anymore and now you got /v2/exact_weather and /v2/broad_weather. Both different to /v1/weather. exact_weather only accepts city names of cities with a population over 1 million, is now a paid service and returns weekly weather instead of daily. And /v2/broad_weather does not accept city names anymore but only coordinates, is still free but locks you out after 10k monthly requests and returns daily weather but without rainfall info.

So a "in between API" won't save you from dabbling with the change from v1 to v2.

And on top of that, now you have two APIs that will change from time to time. The weather API and the Merge/Nango API.

For services Nango supports, they manage all of the things you are talking about - upgrading the APIs, etc. You call weather, you get weather from the APIs you have enabled. They’re selling the management of the complexity you’re talking about.

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.

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.

We use Nango for https://fillout.com and it's been a great addition to our tech stack. Has made it much faster to add new integrations without having to navigate OAuth docs each time

I never understood the raison d'être of such pipe-connecting services for B2Bs. If some data flow is business-critical, why would I want to outsource (and route) an already fragile interconnection to yet another party? Since you're addressing developers, I assume they should know how to plug into an API.

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.

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.

Enterprise sales is essentially just promising more and more features that don’t exist until they sign a contract, then developing the crappiest least-effort implementation to not lose the contract.

That’s my anecdotal experience. So this library fits perfectly with that goal.

(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!

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.

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.

Looks like a cool product with the front-end integration but looking at the license, I can't understand how I'm supposed to use it when you use an Elastic license.

While I understand Elastic's goal of preventing other companies from just rebranding Elasticsearch and selling it as it is, I would probably use Nango as it is and build a front-end layer on top of it for my side projects as I thought this is the main use-case. Can you elaborate more on the license?

(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.

So let's say I want to build a service that lets people access all their libraries from multiple streaming services. Can't I automate all the backend with Nango and just build a front-end around it? If yes, wouldn't it be just rebranding Nango? If not, it would be nice to clarify in the docs.

My point is that if there is no clear boundary, it's too risky for me to try this product even if it's open-core. For Elastic, their boundary is "database as a service" but I don't see anything similar in your license.

Ok I see. Indeed, it would be worth specifying what the boundary is in our case. Thank you for the feedback!

Good to see you all launch on HN! I'm a founder @ https://revert.dev and we are building something similar. Competition is always good for the users.

If you like Nango, you'd love us! ;)

Unified API is a holly grail but as many said quite difficult to abstract every use case in a scalable way that won't break. At CloudQuery (https://github.com/cloudquery/cloudquery) we focus solely on the ELT use-case(Founder/Maintainer here).

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

After spending a reasonable amount of time looking for an answer on the site: Assuming I have a SaaS with some third-party integrations that don't need Nango, why am I taking on the business/technology risk of this external dependency to do "custom" integrations?

(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!

Can you share an example?

For example, if you want to synchronize a specific object type, you would get: the authorization for the API, a helper for paginating requests, easy data deduplication, resilient background syncing, rate-limits handled, and a way to get the data that's unified across APIs and use-case: `nango.getRecords('zendesk', 'user123', 'ticket')`. And you benefit from the tooling around: all sync runs are logged, you get alerted on Slack on errors, you can inspect your integration activity per end-user, etc.

This looks great, and we're in the market for it, but we use JVM tech and would need a client :(

I'd be happy to join the Slack and chat.

(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!

I can see this saving a lot of time! Great work!

How do you compete with Codat.io?

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