Earlier quoted context omitted.
Likewise - Zapier co-founder/CTO here - really excited about this launch. It represents a complete re-build of our stack to support workflows. Pretty much anyone can build complex workflows from a pretty easy to use UI. To call this out specifically - I think HN might appreciate the Code steps you can add to your workflow - we support both Python [0] and Javascript [1] today. I've been using it to replace dozens of c…
We love Zapier and I'm really excited to start playing around with this. One concern I've always had as an engineer using Zapier was how it accounted for unique trigger events. 1. Concerning privacy, for API's that don't offer webhooks for instance, does Zapier poll the API and then store some of our data in order to confirm that new records are indeed new? 2. Concerning robustness, what insurance is there against an…
1. We store a hashed unique id for polling deduplication for as long as your zap is on. We don't store "all" data for all items "seen" in this case.
2. The nice thing about polling is even if we miss a beat here or there - catching up is crazy easy. This is usually no problem at all.
Reliability is actually a big push for us in 2016 - while we are already pretty good we want to be provably safe for mission critical stuff. Keep an eye for some transparency/service status stuff from us this year.
More details since you linked to data privacy:
The task history stores all the data around a task that fires, we've found it is critical for transparency so users can see what happened when and with what data.
The raw logs (think outbound HTTP API calls) are stored for 7 days max and are absolutely critical for us determining just what an account is doing in the system. We just roll them off after 7 days for security reasons.