hsyyid

Yup! That is one possibility. We offer an API so you can query all the available objects inside a user's Salesforce account, and from there you can have the user select what specific objects are relevant, and those will be pulled through.

Great question! Instead of dealing with race conditions like this, we encourage users to use our webhooks to create a workflow.

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.

Thanks! Super excited to be a part of the Meltano and Singer communities as they grow. Excited for what you guys are building.

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.

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!

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.

Yup! Several of our users send things like journal entries and invoices directly to Quickbooks/Xero/Intacct, and more.

Oof... thanks for the advice.

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.

Appreciate the feedback, glad to hear our approach resonates with you :)

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).

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.

Fantastic! Happy to discuss with you further, feel free to make an account and try the Salesforce integration :)

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.

Ah, thanks for letting me know!