6 ms·

Show HN: Nango – Open unified API for product integrations

106 points by rguldener 3y ago

Today customers expect every SaaS product to integrate with the other tools they use. Nango is a tool for engineers at SaaS companies to help them ship integrations fast, without compromising on the integration’s depth and quality. It supports more than 100 APIs out of the box. Other integration companies have focused on building a lot of pre-built integrations. These are fast to ship and low maintenance, but they limit how deeply you can integrate with the external APIs. We take a different approach: we make it easier for developers to build and maintain product integrations in code. This lets you create exactly the integration your customers need without compromising on speed and maintainability, and without having to build complex infrastructure (OAuth, retries, rate-limit handling, change detection, monitoring & logging, alerting, etc.). Our platform has two layers: (1) An API-agnostic infrastructure built with Temporal and Postgres, and (2) lambda function-like integrations written in typescript by any developer. Integrations are rarely more than 50 lines of code (here is an example: https://bit.ly/nango-example https://bit.ly/nango-example), thanks to the developer tooling we’ve built in: authentication, pagination, retries, change detection, rate-limit handling, monitoring, Slack alerts, etc. We have pre-built integration templates you can clone and extend—or you can build entirely custom integrations. Your integrations live in your repo and are tested and deployed to Nango with a CLI. In your product, you use a single API to interact with all your integrations. This lets you easily grow the available integrations with minimal code changes in your product. As a community-driven project, anybody can contribute integration templates and APIs to the platform. In fact, more than 30% of the APIs we support today have been contributed by our community. Nango grew out of a “universal OAuth” project called Pizzly and powers the integrations of 100+ SaaS products today. We have an active community of 800+ developers (https://nango.dev/slack https://nango.dev/slack). All auth-related features are free forever, and we monetize with sync-related features. The entire code base and all integrations are source-available: https://github.com/NangoHQ/nango https://github.com/NangoHQ/nango. We hope Nango can help connect all SaaS products together and look forward to your feedback!

zicon35 3y ago
Good to see you all launch on HN! I'm a founder @ https://revert.dev https://revert.dev and we are building something similar. Competition is always good for the users. If you like Nango, you'd love us! ;)
marban 3y ago
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.
- esafak 3y ago
  Wouldn't it be easier to share the work of updating the integration code when the API evolves?
- kspacewalk2 3y ago
  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.
- btown 3y ago
  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.
- bastienbeurier 3y ago
  (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!
harrisonjackson 3y ago
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.
- bastienbeurier 3y ago
  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).
CharlesW 3y ago
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?
- bastienbeurier 3y ago
  (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!
  - CharlesW 3y ago
    Can you share an example?
    - bastienbeurier 3y ago
      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.
TekMol 3y ago
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?
- ne8il 3y ago
  If it's like https://www.merge.dev/ 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.
  - TekMol 3y ago
    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?
    - mbesto 3y ago
      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.
buremba 3y ago
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?
- bastienbeurier 3y ago
  (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.
  - buremba 3y ago
    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.
    - bastienbeurier 3y ago
      Ok I see. Indeed, it would be worth specifying what the boundary is in our case. Thank you for the feedback!
101008 3y ago
How do you compete with Codat.io?
- bastienbeurier 3y ago
  (Nango co-founder here) Codat is focused on financial integrations, and Nango is transversal, so you can have all your integrations on one platform.
jedberg 3y ago
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?
- 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 ago
    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.
sgammon 3y ago
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.
- bastienbeurier 3y ago
  (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!
dominicwhyte 3y ago
We use Nango for https://fillout.com 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
ssddanbrown 3y ago
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 https://github.com/NangoHQ/nango/issues/900
- bastienbeurier 3y ago
  (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.
  - ssddanbrown 3y ago
    Sure, I understand and respect the desire to protect your efforts. Thanks for responding and being receptive!
aidog 3y ago
I can see this saving a lot of time! Great work!
yevpats 3y ago
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 https://github.com/cloudquery/cloudquery) we focus solely on the ELT use-case(Founder/Maintainer here).
- bastienbeurier 3y ago
  This looks very interesting, congrats! Do you support write-backs & workflows?

106 points by rguldener 3y ago

zicon35 3y ago

Good to see you all launch on HN! I'm a founder @ https://revert.dev https://revert.dev and we are building something similar. Competition is always good for the users. If you like Nango, you'd love us! ;)

marban 3y ago

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.

esafak 3y ago
Wouldn't it be easier to share the work of updating the integration code when the API evolves?
kspacewalk2 3y ago
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.
btown 3y ago
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.
bastienbeurier 3y ago
(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!

harrisonjackson 3y ago

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.

bastienbeurier 3y ago
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).

CharlesW 3y ago

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?

bastienbeurier 3y ago
(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!
- CharlesW 3y ago
  Can you share an example?
  - bastienbeurier 3y ago
    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.

TekMol 3y ago

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?

ne8il 3y ago
If it's like https://www.merge.dev/ 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.
- TekMol 3y ago
  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?
  - mbesto 3y ago
    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.

buremba 3y ago

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?

bastienbeurier 3y ago
(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.
- buremba 3y ago
  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.
  - bastienbeurier 3y ago
    Ok I see. Indeed, it would be worth specifying what the boundary is in our case. Thank you for the feedback!

101008 3y ago

How do you compete with Codat.io?

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

jedberg 3y ago

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?

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

sgammon 3y ago

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.

bastienbeurier 3y ago
(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!

dominicwhyte 3y ago

We use Nango for https://fillout.com 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

ssddanbrown 3y ago

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 https://github.com/NangoHQ/nango/issues/900

bastienbeurier 3y ago
(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.
- ssddanbrown 3y ago
  Sure, I understand and respect the desire to protect your efforts. Thanks for responding and being receptive!

aidog 3y ago

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

yevpats 3y ago

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 https://github.com/cloudquery/cloudquery) we focus solely on the ELT use-case(Founder/Maintainer here).

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