4 ms·
(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
by bastienbeurier 3y ago
(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.
- cateye 3y agoI 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.
- bastienbeurier 3y agoThese 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.