Launch HN: hotglue (YC S21) – Easy user-facing SaaS integrations
We came across this problem while working for a startup that was struggling to scale the Salesforce integration they built in house. We needed a tool that would sync the customer data from Salesforce directly to our backend, but there were very few solutions available. After talking to other engineers who had dealt with user-facing integrations, we found many teams were frustrated by building their own integration solutions from scratch (not to mention maintaining them). This inspired us to build a tool that helps engineering teams add integrations to their products without taking on more tech debt.
Often people are surprised this isn’t solved yet – what about all the data movement tools like Meltano, Airbyte, Fivetran, Stitch, etc.? The difference here is that the integrations we're talking about are not back-end things like pulling your own Google Analytics data to BigQuery so that in-house analysts can work on it. Rather, it’s things like importing a user’s Quickbooks or Salesforce data into your product so that your product becomes more useful to them. That’s what we mean by “user-facing”.
There are a few reasons why building such integrations in-house is tricky. SaaS platforms and their APIs vary widely—while products like Stripe offer stellar APIs and resources, other platforms run on legacy software requiring more involved integrations (such as closed-access APIs or legacy SOAP/XML systems). Second, reliability while syncing at scale can be a challenging task when onboarding users with higher volumes of data – no engineer wants to spend their weekend debugging why their infra crapped out. Lastly, building auth flows and handling API tokens can be cumbersome: catching permission errors and expired tokens can take hours of debugging when dealing with the more "enterprisey" business products.
In short: it’s a pain to have to build one of these for several different apps, and not the sort of thing anybody wants to specialize in. Projects to build these usually end up on the back burner, frustrating customers who expect your product to integrate cleanly with all their other business apps.
We make it easier to build user-facing integrations by providing a scalable framework that minimizes maintenance. Our integrations are built on open source Singer.io connectors that eliminate the need for you to directly interface with APIs (saving you from dealing with breaking API changes, rate limits, authorization, and more). We provide a catalog of all the data each source provides and allow you to pick the data you need without having to grok long API docs. This also means you aren't locked in to our library of connectors – you can write your own connectors in Python. From there, we orchestrate syncing data for you. Just set a schedule, or kick off a job via our API – we provide the infrastructure, so you don't need to worry about building a data pipeline from scratch.
Although we are minimizing the dev work to build an integration, we are *not* a no-code solution. In our experience, no-code tools can be powerful for simple use cases, but are often too restrictive to handle custom logic. hotglue features a Python transformation layer to enable you to manipulate the raw data from third-party apps before it gets to your backend, cherry-pick the data you need, and implement more complex logic. For example, you can join multiple tables, filter out data based on a complex expression, make API requests, write custom logic for specific users, and more.
We are super excited to share hot...
63 comments
[ 3.7 ms ] story [ 137 ms ] threadLooks awesome!
Thanks!
https://fortune.com/2020/08/31/crypto-fraud-io-domain-chagos...
I launched a service on .io in 2012 and moved away to a less-good .com in 2016 - apart from the political issues, its registry services feel & look very ancient. I almost lost the original domain through a forgotten password!
We have made it our mission to provide affordable domain name options for the many entrepreneurs, small businesses, and individuals who need or want more options without extreme limitations, and they deserve to be treated the same as those using legacy TLDs. Our Anti-Abuse team successfully combats abuse with the assistance of our numerous cybersecurity partners and contributions from individuals in the community like yourself. This plus providing education on false information helps protect the reputation of all our amazing end users like HotGlue in the .xyz community.
We feature many of these successful businesses and prominent individuals using .xyz domains every Wednesday since 2014. Check them all out here: https://gen.xyz/ww.
the spam haultd rated xyz quite high on soam so stay away from it
I will be using this if this is the case and we can make sales, and refund receipts and add links to invoices.
How much data can we update or pull. Quickbooks has a lot of quarks.
As mentioned in our post, all of our connectors are open source and built on Python, so our engineers regularly add support for new endpoints as users request them.
Our goal here is that users can trust their data is being handled correctly because we sit in the middle – much in the way Plaid handles personal financial data for specific applications and "sits in the middle." Although using something like Plaid introduces a potential for privacy issues, they likely can achieve a higher level of security and maintain data privacy better than a single application could.
This seems like it could drastically cut down the build time.
Although Powered by Fivetran could be used for the use case we're building towards, it only solves the "getting data out of Salesforce/Quickbooks/etc" part of the problem. Often the harder part is actually extracting the relevant data and working with it after getting it from an API.
Tray advertises a no-code solution and it has to be the most brittle part of our entire platform. It’s common for their API to time out for even the most basic things, like listing which integrations a customer has setup (which is never larger than a handful).
Excited to see this isn’t “no-code”
Cheers!
TL;DR: codat.io is more like Plaid in that they've come up with a single schema for everyone else to build against. hotglue allows you to come up with a schema that works for your product, and gives you the tools to standardize data the way you want it. Because of this differentiation, hotglue is better suited to capture more from each API and can even handle custom data.
I think the easiest way to explain the difference is that codat.io has more closely followed Plaid's model. They standardize all the data upfront to a schema they have come up with, and then give you access to an API to query it.
Although that model works well for simple things like bank transactions where the fields are relatively uniform across different platforms, in something like accounting the fields can be quite different. For example, a journal entry in Quickbooks can have much more data linked to it than what's called a "manual journal entry" in Xero. Because of this, hotglue is designed to give you full coverage of all the data within each platform, rather than limiting you to the data that's available across each one. This becomes even more relevant when users have stored custom data inside of these platforms, which is possible in platforms like Salesforce.
Your low end pricing (i.e. startups & starter packages) seems expensive. For sure it might be worth the value but I feel like it may create some friction for new product builders. What do you think about that? Do you have any plans to re-evaluate or are you pretty set on that for now?
It may seem expensive, but with the products we serve, typically a few users for our customer would cover the cost of hotglue.
2. Is hotglue able to handle large backfill jobs or jobs with arbitrary input data sets?
For example, if I wanted to sync my user's sales data and then relate it to the invoices from the accounting data, I could kick off a sync for the sales, and save that data into what we call a snapshot. From there, I would get a webhook when the sales data was ready, at which point I could start the sync of the accounting data.
Yes, we can handle large backfill jobs (ie. all the data up to the present), and then we incrementally sync new data.
Hopefully that answers your questions – happy to clarify.