72 karma · joined January 15, 2020
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.
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.
Cheers!
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.
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.
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.
Thanks!
Is it's main function a documentation resource? I am currently going through SOC 2 cert audit and a tool like this may be useful for explaining our infra :)