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