I worked on a system that implemented OAuth against maybe a half-dozen APIs. None of them were the same. It's a series of rough guidelines, a pattern, not a spec.
The extra annoying part is that learning each auth is basically a single-use exercise. Sure, you get better from 0-5 but from 5-100 it's mostly just grumbling and then trying to forget whatever esoteric "standard" was implemented.
Source- done over 300 system connections. Save the straight API keys, they're all special and unique snowflakes.
See also: EDI / EDIFACT / ANSI X12.
It was supposed to standardize the way businesses exchange data, but every company implements it differently so integrations take forever, and there's an entire of middlemen offering solutions to make it faster.
I've read the RFCs several years back and they did not feel clearly written, not like a protocol spec. Maybe it was just me. The reality is each OAuth implementation is unique. Almost no two are the same.
All the problems mentioned in the blog post are due to the providers not following what the spec clearly said.
If you have an example of where that's not the case, I would also love to hear as I work in this area (perhaps you're thinking about how OAuth does not specify at all how authentication happen? But that was a good call, OAuth 1 did and it was too limiting... also OpenID Connect is pretty widely adopted now, and it fills that gap well).
What that tells me is that people who cannot read and understand a specification (or willingly ignore what the spec says) are implementing it anyway. I claim the spec is completely clear on all the points raised in the blog post. You can't just handwave that away without specifically telling what point was unclear.
It handles the API-specific complexities (auth, retries, webhooks, per-customer config, pre-built templates) but allows you to implement the exact use case + data model you need.
We use infisical to manage 100s of secrets in our various environments. Honestly don’t know how we coped before it.. Makes it very easy especially for a team where devs jump between projects. It has a few areas which can get frustrating and they had a few bugs some time ago.. but it has been a excellent improvement in our workflow for day to day dev and deployment.
I think there will always be a use case for Zapier to cover the very long tail of integrations.
But we want to make it easier for engineers to offer their customers the native integrations they need.
Usually, these cover the most important and most valuable use cases. But they are often also the most complex to build (e.g. reliable 2-way data syncs)
I think there will always be a use case for Zapier to cover the very long tail of integrations. But we want to make it easier for engineers to offer their customers the native integrations they need.
This is a better description of your product than what you wrote in your original post. Maybe worth iterating to see what resonates with your target audience.
e.g. reliable 2-way data syncs
I'm curious about this. Can you give a real-life example of a 2-way data sync you or your users have set up?
Can you give a real-life example of a 2-way data sync you or your users have set up?
Sure:
- A support SaaS uses Nango to sync contacts & companies with CRMs (Salesforce, HubSpot, etc.)
- A billing SaaS uses Nango to sync invoices, customers, etc. with accounting systems (Quickbooks, Netsuite, etc.)
- A security-focused SaaS uses Nango to create issues in Jira, Linear, etc., and then syncs the status & other properties between these apps and its own product
If Zapier is your mental model, the use case there is trigger/action workflows which is a different from 2-way sync which I'd say Nango does well. For the former you might want to check out this open-source project I work on: https://github.com/RolloutHQ/rollout
https://nango.dev is another open-source option (disclosure: I am one of the founders).
We have heard the opposite argument for AI agents:
The people we spoke with want control over what the AI agents can do in the external systems. With direct API access and non-deterministic behavior, how do you guarantee it doesn't swap the POST /contacts with DELETE /contacts?
Integration platforms that abstract the API provide a safety net for this, and auditability.
Big fan of Nango. Love what you are doing in the unified api space by providing customisability past the lowest common api denominator.
Reason I did not include you in the open source list is your github only seems to have "integration templates". I may be wrong but these look like helpers for your customers to understand your integration formats. All your integrations do not seem to actually be open sourced. Especially
I agree that AI agents can always misunderstand and call the wrong api. Thus I believe having an open source configuration standard, interoperable with OAS, which AI agents can parse would be hugely beneficial. Audibility of course is also definitely crucial with any AI system.
The fundamental issue I see with API abstraction over the core system is the inability to fully interact with the underlying system for bespoke requests that may come up. Also the issue with the AI systems calling the wrong api (POST instead of DELETE), can still arise with any system an AI interacts with tho I agree that besides securing with appropriate oauth scopes, integration platforms could help with additional guard rails
I think the biggest difference is that Nango lets you customize & extend the unified APIs on the platform.
Usually unified APIs mitigate their limited catalog with passthrough/proxy requests. But this is a partial solution, since you go back to having a lot of integration logic in your code base.
With Nango these customizations live in the unified API itself and benefit from all the infrastructure available there (OAuth, rate-limit handling, pagination, de-duplication of records, etc.).
You can also build entirely custom integrations in Nango.
That being said, I think open-source unified APIs have a ton of promise!
It is great to see the ecosystem grow :)
Our experience was exactly like OP describes: https://www.nango.dev/blog/why-is-oauth-still-hard