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