[HN Gopher] Launch HN: hotglue (YC S21) - Easy user-facing SaaS ...
___________________________________________________________________
Launch HN: hotglue (YC S21) - Easy user-facing SaaS integrations
Hi HN, we're Hassan and David from hotglue (https://hotglue.xyz).
We make it easier for developers to build user-facing integrations.
In this context, an integration is a way for users to sync their
data from their business apps, like Salesforce and Quickbooks, to
another. For example, if I wanted to use an app like Mailchimp, I'd
use their Salesforce integration to sync all my contacts over
automatically. 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 hotglue
with the HN community. We've created a quick demo for you to see
what an integration looks like: Video:
https://youtu.be/ZzSsL66fSUE Interactive demo:
https://bit.ly/3rsLR0G We'd really appreciate hearing your
thoughts, experiences, ideas and feedback. Your feedback is vital,
as it is our dream to make hotglue the standard for building user-
facing integrations. Also, in case you're thinking of adding new
integrations to your product, we would love to help - sign up for a
free trial at https://hotglue.xyz (we have a startup plan) Thanks
for reading this far, and happy Thursday! :)
Author : hsyyid
Score : 96 points
Date : 2021-07-22 13:57 UTC (9 hours ago)
| blooalien wrote:
| Nice. Built on Python. That alone is an instant win for me. Nice
| usage of Jupyter as well. (Still reading through the docs.)
| hsyyid wrote:
| Appreciate the feedback, glad to hear our approach resonates
| with you :)
| Dionakra wrote:
| As someone who browses 4chan from time to time, I found the name
| a bit confusing. Just quick search it on Urban Dictionary.
| nexuist wrote:
| Yeah...but at the same time, it's not like normal people are
| going to know about it, certainly nobody would bring it up in a
| corporate environment or risk outing themselves as some kind of
| weirdo, so it's probably fine? It's not their fault that random
| forums prescribe shock value to regular words.
| rahimnathwani wrote:
| In the demo, you don't need the user to generate and paste a
| GitHub API key, because you can do that after getting access via
| OAuth. Will that be possible for all other taps, e.g. SendGrid,
| Zendesk, Close.com?
| hsyyid wrote:
| That's correct. We did that with GitHub as a short example for
| HN, but most sources are configured via OAuth (as long as they
| support it) - including the ones you mentioned.
| thedangler wrote:
| Can I use this to send information from my app to an App like
| Quickbooks?
| hsyyid wrote:
| Yup! Several of our users send things like journal entries and
| invoices directly to Quickbooks/Xero/Intacct, and more.
| jgautsch wrote:
| Hey congrats on launching- Wanted to drop a note from someone who
| has been burned: avoid .xyz domains like the plague. They can
| revoke your control of the domain at any time if you end up on a
| spamhaus (etc.) list. This happened to me even though I was only
| using my .xyz for a non-prod env shared with a customer. One day
| control of the domain was just taken by the .xyz org and I had no
| recourse other than generic ticket submission.
| kureikain wrote:
| I second to that advice. Im running mailwip.com and I saw a lot
| of spam from xyz domains
|
| the spam haultd rated xyz quite high on soam so stay away from
| it
| sneak wrote:
| This is also true of many TLDs that correspond to localities.
| For example it is a TOS violation to disparage Las Vegas on a
| .vegas domain. Not all TLDs are created equal.
| hsyyid wrote:
| Wow, I had no idea. We're planning to switch domains soon
| [https://hotglue.io] - thanks for the heads up.
| mattbee wrote:
| I'd be wary of .io too:
|
| 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!
| hsyyid wrote:
| Oof... thanks for the advice.
| cocoflunchy wrote:
| Just another data point: I signed up and received your
| confirmation email in my spam folder (gmail)
| hsyyid wrote:
| Ah, thanks for letting me know!
| tpetry wrote:
| And the next problem will be that many mail servers give you a
| higher spam rating for .xyz domains because it's mostly used by
| spammers.
| [deleted]
| emptysea wrote:
| At $work we use Tray to sync salesforce and some other CRMs to
| our database.
|
| 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"
| shoto_io wrote:
| It's really difficult to get people off the no-code train...
| hsyyid wrote:
| Interesting - would love to hear more about what your
| experience using Tray has been like. Glad to hear that going
| against that "no-code" trend is something that you agree with,
| as it definitely gives more flexibility to developers in how
| their integrations work.
|
| Cheers!
| SkyPuncher wrote:
| Timing couldn't be better for us! A lot of our customers are
| asking about a SFDC integration, but it's been hard for us to
| pull trigger on actually building it.
|
| This seems like it could drastically cut down the build time.
| neeleshs wrote:
| shameless plug - look at syncari
| SkyPuncher wrote:
| Thanks! Will take a look as well!
| hsyyid wrote:
| Fantastic! Happy to discuss with you further, feel free to make
| an account and try the Salesforce integration :)
| soumyadeb wrote:
| Doesn't FiveTran provide an API service which one can use to
| build something like this?
| hsyyid wrote:
| Sort of, yes. Fivetran has a product called Powered by Fivetran
| which is an API on top of Fivetran that lets users connect
| their apps and push to a warehouse managed by you. For example,
| you could ask users to connect their Salesforce via Fivetran
| and the data would end up in a BigQuery dataset you own.
|
| 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.
| DouweM wrote:
| Congratulations, Hassan! It's great to see more tools adopting
| the open source Singer standard for connectors, and at Meltano
| we're very grateful for all the taps and targets you maintain:
| https://hub.meltano.com/singer/maintainers/hotgluexyz
| hsyyid wrote:
| Thanks! Super excited to be a part of the Meltano and Singer
| communities as they grow. Excited for what you guys are
| building.
| toomuchtodo wrote:
| Do you provide any sort of debugging logs for troubleshooting
| integration/workflow failures while ensuring those logs are
| sanitized of user secrets? Is there a straightforward way to
| report integration failures for triage by your team in the event
| something changed unexpectedly (Silent API changes happen more
| often than you'd think)?
|
| Looks awesome!
| hsyyid wrote:
| Yes we do! The way it works is we run isolated containers for
| each sync job, and then monitor the process for errors. There's
| a few stages it goes through (syncing the data, running any
| transformations, and then exporting the final output). At each
| of these stages sanitized logs can be viewed in real time from
| the hotglue panel, so developers can debug what went wrong
| (whether it's an expired OAuth/API key, or a breaking API
| change). If there is a case where an integration is failing, it
| can be reported to our team directly in the hotglue panel for
| triage.
|
| Thanks!
| toomuchtodo wrote:
| Brilliant, thanks for the reply.
| kuiro5 wrote:
| Congrats on the launch, absolutely love the name!
| hsyyid wrote:
| Thanks, glad to hear that!
| quadrature wrote:
| Are there data privacy concerns here ?. As a user im making a
| decision to share my data with a specific application but now a
| third party is actually in between us.
| hsyyid wrote:
| Good question. Our tool falls into the category of third party
| data processors (in GDPR speak). That being said, we take data
| privacy pretty seriously, so aside from taking security
| measures and obtaining relevant certifications, we ensure users
| can revoke access to their data and even delete all their data
| if needed.
|
| 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.
| ManBlanket wrote:
| I used to work for a company which provided a service to state
| governments which was funded by a federal program. Long story
| short there are a lot of crazy top-down requirements ranging
| from integrating with a preferred vendor, which was barely a
| start-up amid a market of well established (better)
| alternatives, to the coupe-de-grace which read, "unhindered
| access to all production data". This service seems particularly
| useful to companies struggling to cope with government
| requirements of that nature, particularly GDPR.
| hsyyid wrote:
| Yup, that's definitely a great target for a product like
| ours. Like you said, especially for a start-up in a market of
| more well established products, it's hard to juggle product
| growth with scaling up integrations (and all the work that
| goes into it: from security to API changes).
| Causality1 wrote:
| Differing social circles and awareness may make this concern
| irrelevant, but you should be aware that "hotglue" is a genre of
| pornography. It may never come up but don't be blindsided if it
| does.
| blooalien wrote:
| My first thought seeing the name was "Neat. Glue APIs
| together.", but now I know this other connotation, I'ma need
| some "brain bleach". Sometimes the Internet needs an "Un-See"
| button. ;)
| cocoflunchy wrote:
| Hey, I might be in the market for this although what I'm trying
| to achieve is to push data from my app to partners (Quickbooks,
| Sage) for invoicing. Am I understanding correctly that you
| currently only have integrations that pull data from an external
| tool into my app? Thanks
| hsyyid wrote:
| Actually, we support pushing data as well! We have a few users
| with a similar use case, who push journal entries and invoices
| from their apps to Quickbooks/Sage/Xero, etc.
| thedangler wrote:
| Only thing is I would need my end users to log into
| quickbooks for my app to work is that is what going on here:
| End user logs in?
|
| 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.
| dmolot wrote:
| (I am the other founder of hotglue) yes, all the end user
| does is just log in.
| hsyyid wrote:
| We have pretty good coverage on Quickbooks, but if there's
| something specific you'd want to push or pull that we don't
| support already, it can be added pretty easily.
|
| 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.
| kayhi wrote:
| Especially for accounting, how does your product compare to
| codat.io?
| hsyyid wrote:
| Great question!
|
| 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.
___________________________________________________________________
(page generated 2021-07-22 23:00 UTC)