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.