[zicon35]

* vs Nango - we think they have great support for OAuth management and do support more APIs than ours on the surface (atleast at the moment).

Nango is based on Pizzly an existing OSS project which they built on top of. We're building it from the ground up.

Even though they seem to have more integrations, our integration support is better than them in terms of the depth of use-cases allowed (more standard objects supported, custom properties, field mapping support, custom objects (soon) etc).

A few prospects of ours tried out Nango for this use-case and then came to us eventually.

* vs Merge - we'd be able to fly past the number of integrations offered by them being an OSS product especially because of community contributed integrations. Being a developer first product, open-source is the way to build the best product in this category.

Integrations inevitably have edge cases that you would run into and you as a customer might require Merge to behave in a certain way. The typical response at a closed-source SaaS company would be that its on "their roadmap", never to get back again. This holds you tightly with their roadmap velocity and you're locked into a vendor.

Being an open-source product you, the engineer, will be able to fix or add integrations right away in the worst case if nothing else. This way of operating is very powerful we think.

Also, we don't cost you an arm and a leg :)

[t1mmen]

I love these kinds of products, and welcome any competition in the space. But, this comparison to Nango doesn't seem accurate, so I feel inclined to comment.

Please correct me if I'm wrong, but you say...

> Even though [Nango] seem to have more integrations

Nango has north of 100 integrations, Revert seems to have 4 atm?

> our integration support is better than them in terms of the depth of use-cases allowed (more standard objects supported, custom properties, field mapping support, custom objects (soon) etc).

How so?

Nango Sync gets you easy access to the raw API responses from the 3rd party service, and lets you map that to whatever shape/model you, as the implementer, want to end up with.

Revert seems to return standardized/normalized objects per data model (e.g, company, contact, task) across the 4 different integrations currently mentioned. It also seems to support "custom mapping" past the "lowest common denominator" schema, by adding `sourceFieldName` -> `targetFieldName` mappings (but seemingly only for picking out response key if they're strings, not any "pick from object", or "compute based on multiple properties"?)

Please don't take this as discouragement -- it's a great space to play in, and there's a lot of room for improvement. But, as a _very_ happy user of Nango over the past 10+ months, I feel you should compare yourself honestly at the very least.

Good luck!

[zicon35]

Hi! Thanks for your comment.

> Even though [Nango] seem to have more integrations

We agree Nango has more integrations and we love OSS software so I'm with you on this. Credit where credit is due and we don't want to make false claims at all. We never claimed to have more integrations than them. I'm not sure how what I posted came off as dishonest.

> but seemingly only for picking out response key if they're strings, not any "pick from object", or "compute based on multiple properties"?)

I'd say we support this perhaps in a different way.

I have not used Nango myself to comment on specific ways it handles data vs how we handle it.

Its great that you're liking Nango and we want OSS/better product to win regardless.

[t1mmen]

Yeah, sorry, I just got caught up in your wording. Since you asked: "Nango seems to have more integrations" feels disingenuous, when you're comparing 4 to 100+. You'll likely be asked to compare yourself with Nango a lot, so it's not a bad idea to know what you're up against.

In any case, I wish you the best of luck with the "one model per resource type" concept you're trying. It's a tricky one, since you're usually stuck with the lower common denominator.

I expect many, if not most users will need additional custom mapping (so if "field A" -> "field B" mapping is the only option for now, expect to run into lots of feature requests that need to pick from objects/compute multiple values into one field. DX around this will be important)