Skip to main content

Get Support
Have a question? Let's get you an answer!

How Do I...? Troubleshooting Code & Webhooks Developer Zone

Other Help Resources
Wait, there's more! Check out these Community sourced spaces for additional resources.

Zapier Help Center Hire an Expert

Learning Resources
All of our best learning resources can be found here.

Featured Articles Show & Tell Zapier's products AI Hub Zapier Tools Hub

Share your knowledge
Give back to the Community by sharing your automation wins and helping to answer questions.

Share your success See unanswered questions User Groups

Other Learning Resources
Some of our favorite additional ways to upskill your Zapier knowledge.

Zapier Learn Zapier Blog Zapier Webinars

Product Updates
Check out what is new and upcoming with Zapier with our regular product updates.

Product Updates

Early Access Program
Want to join Early Access? Learn more here.

Hi all!

We have existing polling triggers that are actively used by some of our customers. We’re concerned about the time it’s taking on our end to respond when our endpoint is hit, so we’ve started looking into what would be required to use REST hooks instead. Since our customers already have several zaps setup using our triggers, we would like to make the switch in a way that they could keep using their existing zaps while also benefiting from our switch to REST hooks.

  1. Is there a recommended process for updating triggers from polling to hooks and migrating existing users to the new version?
  2. I’m concerned that migrating existing users to the new trigger version with hooks risks missing any events that occur between the last poll of the previous version and the migration to the new version. If that’s a valid concern, is there a way to mitigate the potential for missed events in that window?

Thanks!

This is a great question. You’ll need to treat the switchover from polling implementation to REST hook implementation as a breaking change. The reason: Zapier won’t automatically fire off the subscription for those hooks after migrating, so, if you migrated the Zaps they’d effectively be paused.

So, to effect the breaking change you have a couple options. 

  1. Give your new version a major version bump to indicate the breaking change, say 1.0.0 → 2.0.0 so you remember not to try to migrate users from one to the other. Promote 2.0.0. New users will take advantage of the better implementation, existing users will continue to use the existing version until they upgrade their Zaps.
  2. Similarly you can mark today’s trigger hidden, add the new trigger as the visible one, and then you can migrate all users to a single new version of you integration. Existing Zaps keep working on the hidden trigger. Any new Zaps will use the new one. 

Either way usage of the old polling trigger will gradually decline over time. I’ll invite comment from others on the upsides and downsides they’ve seen for either approach - and any ideas on how we can create a better developer and user experience through breaking changes like this.

Thanks @Zane ! One question: for option 1, in which we make a breaking version of the integration, will the subscription fire immediately when the end user upgrades their own zap? Or will that also effectively pause the zap?

A user would end up pausing the Zap to upgrade it (selecting the newer version of your app in the Zap editor). As soon as an edit, any edit, is made, the Zap automatically gets paused. When they finish editing and turn it back on, the subscription will get created. 

Terms & Conditions