bastienbeurier

If you are interested, we are working to solve these shortcomings at nango.dev.

Instead of having a black-box unified API, you can define the schemas/interactions between Nango & external APIs, in code. Which means you can do detailed data validation, specific to your use case, so you get back fully-typed objects. You control the data transformations to match your specific use case (so when APIs have different values for, let's say, "contact status", you define the mapping). You only sync the data you need, not full objects, so it's efficient.

A call to fetch records looks like this:

curl --request GET --url 'https://api.nango.dev/records?model=MODEL-DEFINE-BY-YOU' --header 'Connection-Id: YOUR-CUSTOMER' --header 'Provider-Config-Key: EXTERNAL-API'

Curious to hear what you think!

Standard pre-built integrations are ok to get started. But rapidly customers ask for more integration capabilities, which are not supported by standard integrations. At this point, SaaS companies need to build custom integrations that fit exactly what they customers want.

The players you mentioned pre-build standard integrations, in specific categories (e.g. HRIS). We build a platform that lets developers build custom integrations, for any API.

We do offer integration "templates", but it's only a way to get started and templates are meant to be extended.

That's also why our catalog of APIs is extensive. Anybody can rapidly add support for any new API and start building custom integrations for it, and share templates with the community.

We've noticed the same pain point and we are providing increasingly better support for ERPs. Realistically, it takes time to build expertise on each of them, but we'll get there!

The main difference is that Merge pre-builds all integrations, with limited customization capabilities, while Nango gives you full control over the code of the integrations.

Yes, this works, and it's a feature we offer for free!

Some integrations are connected at the org level (one account for the entire company), and others at the user level (many accounts per company). For the latter case, the pricing per connection is lower.

Thank you for the insights and looking forward to chatting!

It does!

Because Nango lets you define input & output models of integrations, it's easy to standardize them across APIs.

So, when syncing users from Slack/Discord/Teams, you define a standard User model, and all 3 integrations map to this model.

You then consume User objects from a unified endpoint, regardless of where they come from.

1) That's right!

2) You can write your own integration scripts, in code, consuming any endpoint from the external API, so you are not limited to what Nango pre-builds (details: https://docs.nango.dev/understand/concepts/scripts).

But you can also access the original API through the proxy, which will inject credentials, log requests, help you with pagination (details: https://docs.nango.dev/understand/concepts/proxy).

Nango | Backend Engineers | Full-time | Remote (US/Canada East & Europe) | https://nango.dev

Nango is a developer platform to build product integrations 10x faster.

We’re 5 veteran engineers (Uber, Netlify), repeat founders who did YC multiple times, top US investors back us, and we have more customers than we can handle!

Please apply at https://nango.dev/jobs

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

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.

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

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

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.

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

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

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

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

That's what we do at http://nango.dev