Recommended path for switching existing polling trigger to REST hooks?

Question

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.Is there a recommended process for updating triggers from polling to hooks and migrating existing users to the new version?	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!

Zane · Accepted Answer

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.

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

preston · Answer

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?

Sign up

Use your Zapier credentials

Log in to the Community

Use your Zapier credentials

Scanning file for viruses.

This file cannot be downloaded