Show HN: Revert – Open-source unified API for product integrations
github.com
github.com
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.
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.
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!
What’s your quick pitch for why someone should use Revert vs competitors like Merge.dev and Nango?
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 :)
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!
> 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.
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 :)
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.
Maybe just a book a time with us or DM us Twitter and we can take it from there?
Happy to take issues here and we could prioritise them based on the interest of our current customers/prospects: https://github.com/revertinc/revert/issues
Given the tiny number of APIs supported today, encouraging the community to add more APIs seems like it should be the #1 priority.
I didn't see any sort of tutorial on adding new API's on either the homepage or the GitHub readme.
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.
We launched v early tbh!
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.
Happy to answer any follow ups here!
And Additionally, what kind of support and assistance does the Revert team provide to facilitate this setup? If a client needs it.
- We're coming up with other easier ways to self-host at the same time. Our friends at Scoutflo (https://deploy-home.scoutflo.com/) & https://nuon.co/ are building something cool for this.
- 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.
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. :)
- is it easy to deploy from test to prod via CI?
- is the configuration source-controllable/diffable via Git?
Ta!
- 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.
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?
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.
Just book a time here: https://cal.com/allenrevert/30min
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.
We're different from n8n in the sense that we help you build native integrations with APIs and not in a no-code way.
We will help you build an integration of Slack (for eg) within your product with your users/customers, natively.
That means, your end-users or customers will not know that you are using our APIs underneath as Revert can be fully white-labelled.
We don't offer a workflow UI like n8n at all.
Happy to answer any further questions on this. Feel free to book a time from our cal if you think this could be relevant for you!
Cheers.
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.
You could book a time with us, happy to chat further: https://cal.com/allenrevert/30min
1. Agreed on this! We plan to offer this as a service along side our API offering at some point.
2. We’d be adding more authentication mechanisms soon so API tokens will be supported alongside OAuth.