Skip to main content

My client wishes to remove the ~5 minute delay from Quickbooks to Airtable via a Zap I have set up for them.

I have two options as I see it: Option A. create my own application for Quickbooks Online on the Zapier platform, but from what I'm reading that would not shorten the 5 minute polling time.

Option B create an app on the intuit/Quickbooks platform and have that call a webhook (in Zapier) each time an object is created/modified etc.

My questions:

  1. Am I correct that polling triggers in an application I build for Zapier would still operate at the ~5 timeframe?
  2. Anyone have experience with using Webhooks from QBO to Zapier, any "gotchas" or heads up that I should know about?

Thanks!


  1. Yes, that is my understanding
  2. Sorry, no experience there



Hey @PaulKortman, @Openside is correct. Creating your own app would still respect the polling time. The only way to get around this for the time being is to move forward with utilizing webhooks to send information as soon as updates occur.

We'll leave this thread open incase anyone with experience using webhooks with Quickbooks has any advice they'd like to pass along to you. :)



Can't speak to QBO aside from aside from trying to use their API docs and their sandboxed environment for a client 7-8 months back and it is absolutely horrid. After 5-6 hours of trying to get things working, I eventually gave up on it. Their sandboxed environment is super confusing and not user-friendly at all, I wouldn't recommend going that path at all. Though if you do, good luck and please report back with how it goes!

On the other hand, I can speak to Help Scout (totally unrelated, but I can speak to polling quite deeply with it). They have a native Zapier integration (which has a 5 minute polling trigger), so we are using (as Jessee suggested) the "webhook" trigger functionality instead and are able to have the data send over immediately.

It's super helpful, but you typically get a more "raw payload" of sorts, and a more general trigger. Sometimes the app will give you options to only send the payload when XYZ happens, but you're typically fine having it be pretty general and then just using Zapier filters/paths to have it do what you need it to do.

Another tip is that Zapier supports receiving of multiple webhook triggers in one go, so say the sending app only supports for one "webhook post", you can turn it into many by just adding a /webhook ID like:

https://hooks.zapier.com/hooks/catch/1234

/v1234d/j1234f/z1234j

That will trigger a webhook send to:

  • v1234d
  • j1234f
  • z1234j

There's specific Zapier documentation on this point somewhere, just couldn't find it and remember being super excited upon finding this out so just thought I'd share.

Anyway, so the positives of a webhook trigger are immediate trigger (instant polling). The downside of using a webhook as a trigger (if the software provides the option), is that it's a bit more difficult to manage/setup, typically more of a broad trigger (versus the usually specific trigger options within a native Zapier trigger, which is sometimes a positive if the Zapier trigger options are too specific), and now you have 2 places in which the connection is taking place. In the software you have a link to the Zapier webhook, and in Zapier is where you have it configured, versus just having Zapier as the main place where you need to edit from time to time.

Best of luck!