Hi HN! Allen & Jatin here, co-founders of Revert.dev
Integrations require a lot more engineering time, resources, and ongoing maintenance than you would first expect.
When building your own integrations you have to deal with challenges, such as:
- unreliable third party integration endpoints, which fail or hang more often than you think;
- monitoring and reliability of the integration code; dealing with different schemas, gotchas, rate-limits of the various APIs you integrate with.
- You need to do this all alongside maintaining your own code base.
This is what we’re solving for at Revert.
With Revert you can ship a reliable product integration in under 2 days, and we take care of all of the above and more.
- We current support CRMs such as Salesforce, Hubspot, ZohoCRM & Pipedrive through our APIs.
- We’re open-source (https://github.com/revertinc/revert) and want to build the project with the community in the open. If you’d like an integration you can add one & welcome contributions!
* 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.
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.
> 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.
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)
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 :)
Do you have any resources for the planning/architecting phase of developing a unified API like this?
I work in a similar space, but for physical hardware, and one challenge we've frequently encountered is the somewhat massive variety of how our vendors handle certain tasks behaviorally within their platform.
We believe an open source unified API enables us to cover the long tail of third party APIs while empowering engineers to customise the integration code we offer out of the box.
This way engineers can use us over building an integration from scratch. Even if that means that they use the self-hosted version and not the hosted version that we have.
The pricing page (https://www.revert.dev/#pricing) doesn't even mention it ("self-hosted" or "community" or something like that). Or is that intentional to cater different audience?
Hi, open-source/community edition is free and you can just host it via docker compose in your own infra. We're adding that to the pricing page as well very soon.
The other aspect of this is that our community is helping us build integrations much faster.
Our customers (i.e, developers) can also help us build a better product. This way it helps everyone in the long run and developers are not repeating this work again and again!
We're getting a few community contributions out this week into Revert in a very hands-on way.
This way we'd learn how to best optimise the product to allow for community contributed integrations at scale and the tutorial will be basis these learnings.
1- How does Revert ensure the security and privacy of data while facilitating integrations through its unified API, especially when dealing with various third-party applications and services?
2- The platform mentions a 'Unified Data Model' and 'Standardised data formats and schemas.' Could you elaborate on how these aspects help in simplifying the integration process across different CRMs and what measures are in place to handle discrepancies or inconsistencies in data formats between various integrations?
* We take security seriously and understand that storing sensitive information is risky. Therefore we're undergoing SoC2 Type 2 for our hosted version to ensure that we follow the best security practices ourselves in how we store data.
* If you still don't trust a third party like us you could use the self-hosted version of Revert and use it in your own infra. (we can assist you in this)
2 - The way we simplify the schemas is such that you don't have to learn the nuances of each CRM for example. (what field X is called in CRM A vs CRM B)
We ensure that you need to learn only the API schema (for example Leads API endpoint) that we offer and in the background map this to the downstream CRM (Salesforce, Hubspot or anything else).
At the same time, we ensure that you can call the native CRM APIs if you need to, without managing the OAuth or refresh of these OAuth tokens.
Thanks, Just one last question from my side- For the self-hosted version of Revert, can you provide more insights into the level of technical expertise required to set it up within an organization's infrastructure?
And Additionally, what kind of support and assistance does the Revert team provide to facilitate this setup? If a client needs it.
- We can do this as a "done-for-you" setup or be completely hands-off and give you just the docker images to go ahead with. This mostly will depend on our customer's needs and bandwidth.
i have probably seen 10 products in this space come and go in way less time than one would think both proprietary and open source. proprietary are either shut down or acquired and made unusable by price explosion or crippling of features. the open source ones always turn stale way before even half of that ambitious integration list has a checkmark, which makes these kind of a joke. relying on something like this seems to never be worth it: the painful parts are usually auth flows and maybe api paging but anything that could cause api mismatch or store data on third party servers is a recipe for disaster. in addition no integration platform i saw that was doing more than hand through the base api surface directly would cover every detail and have quite the level of feature support focus that was relevant to the application. i saw more than once that a company had to add their own app and integration just to handle unsupported cases because they could not afford a complete rewrite to add a critical feature in a timely manner.
Hi! Appreciate the comment and understand the skepticism here.
Well business/startups are tough are in general & more die than survive so you're probably right on those stats.
Would love to know more about your experience specifically though? Which products did you try? What was the use-case you had that made you add your own integration?
I'd love to chat more on this if you'd be up for it. :)
- Yes we give you keys for test environment that you could build an integration with. Once you're happy with it, you could easily just swap out the keys in production that we give you and launch directly. Since we're an API, all the code you write to integrate with us lives within your code base. Deploying is as easy as deploying your code.
- We're all code based so everything you need to integrate with us is source-controllable and diffable. We're not a no-code/low-code solution. We're building it with the developer in mind.
Congrats on the launch! This certainly seems like a product for which a big market exists.
As someone who is dealing with Salesforce integration in my own company, I have a question: how well does the Revert Salesforce integration work with highly customized Salesforce setup? We operate in a complex domain, so our Salesforce setup is customized with a bunch of custom entities in a complex hierarchy. So not just Accounts, Opportunities etc.
Does Revert work with that at all or does it assume a certain default data model?
1. We support Standard Objects (Accounts, Opportunities) and unify them into a simple schema for you to work with. We allow you to work with custom fields on standard objects already.
2. We also allow you to call native CRM apis without the hassle of managing OAuth if you need to. This will allow you to work with any nuances of a specific CRM or CRM instance. Checkout - https://docs.revert.dev/api-reference/crm/proxy
3. At the same time, we are launching custom object support very soon that will allow you to work with custom entities as they are but in a much better way than using the native APIs directly.
I just want to commiserate with you as someone else that’s currently working with Salesforce. Hell, I’m not even working with Salesforce. My product is just exposing an API that our Salesforce team is integrating with. That alone has been sufficient exposure to the absurd environment in which those poor guys are working.
I would really like to be able to be able to pull data out of Salesforce, Pipedrive etc and into our ETL tool (Easy Data Transform), so that users can clean/reshape/reformat the data. However our software is a desktop C++/Qt application, so it doesn't look like a good fit with this. Does anyone know anything comparable for desktop (free or paid)?
Hi, our frontend logic is minimal. Most of the product is the API which can be called from anywhere.
I don't see why this may not work for your use-case too. I'm happy to chat more if you want to just talk tech here and maybe avoid engineering work for your use-case.
Can you explain your thoughts on pricing on the hosted version? $40/connection seems much higher than your competitors and a total non-starter. Most open source projects seem to aim for “healthy margin over self hosting” but with even modest usage (1k connections) this becomes prohibitively expensive.
Our pricing is in-line with B2B customers and the way we define a connection is a single tenant (example: CRM) connecting through our APIs. Within that CRM/tenant, you could make as many API calls as you'd like (upto a certain limit). Usually this means, one connection <> one customer of yours.
If you're a B2C application with a lot more connections happy to chat more and work out a pricing that works for both of us.
here are some tips to differentiate:
1. focus on automating integration provisioning ... ie, dev still have to go through the various third parties they want to integrate with and that is a PITA
2. focus on something other than oauth... api tokens are actually way more straight forward to developers than oauth in terms of setting up
Yes. It’s like Zapier that connects various APIs together but instead of no-code blocks that marketing/sales/product teams use, we are an API itself that developers can use to build integrations that are natively coupled into your product. This way your users don’t really know that you’re using Revert
Integrations require a lot more engineering time, resources, and ongoing maintenance than you would first expect.
When building your own integrations you have to deal with challenges, such as: - unreliable third party integration endpoints, which fail or hang more often than you think; - monitoring and reliability of the integration code; dealing with different schemas, gotchas, rate-limits of the various APIs you integrate with. - You need to do this all alongside maintaining your own code base.
This is what we’re solving for at Revert.
With Revert you can ship a reliable product integration in under 2 days, and we take care of all of the above and more.
- We current support CRMs such as Salesforce, Hubspot, ZohoCRM & Pipedrive through our APIs.
- We also support Slack (in beta) alongside Discord that will be supported this week. Our roadmap is public — https://github.com/revertinc/revert/issues?q=is%3Aissue+is%3...
- We’re open-source (https://github.com/revertinc/revert) and want to build the project with the community in the open. If you’d like an integration you can add one & welcome contributions!
Would love to get the community’s feedback.