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.

We’re developing a connector for our application and we want it to trigger when a value crosses a threshold. Our API just returns the current value as a number (and there’s not a way to call the API to ask “what was this value 5 minutes ago?”). If the zap could remember the previous value it saw, then our connector’s code could check if (previousValue < threshold && currentValue >= threshold) and only trigger the one time it crosses the threshold.

Is this possible?

What we’re currently doing is essentially this:

return i{
  id: value >= threshold ? "above" : "below"
}];

Zapier thinks it’s a new object when the ID changes, but once Zapier has seen both IDs (“above” and “below”) then it stops triggering. We can append the current date to the ID so it triggers once a day at least, but ideally we’d like to only trigger on transitions (i.e. crossing above or below the threshold).

For the best user experience my first suggestion would be executing this logic in the app, and surfacing the event as a subscription webhook, rather than trying to manage state within your Zapier integration.  Sounds like you’ve identified a valuable use case for your users - “notify me when a value changes beyond X amount”.  Hook events are ideal for this kind of use case and make it easy for the user to consume it.  

 

I certainly understand why that’s your first suggestion but I’d also like to know what your second suggestion is :relaxed:

I’d prefer to get things working without having to change our services or API. I’m ok with the latency of a polling-based trigger, if we can get it working that way, since it’d let us build out our connector more easily.

z.cursor sounds like it’s used to store some information between calls for pagination purposes. Can that be repurposed to store other values between runs?

@robotmiller This is a great use case for `z.cursor`! It provides a simple way to store dada per-zap. 

A couple of notes:

  • values are only stored for ~ an hour. This is plenty of time normally (since cursor’s primary use is paging) but your app should handle a cache miss gracefully
  • all values are stored as strings, so make sure to re-cast to a number when you do z.cursor.get() to make sure your math comparisons work as expected
  • Sounds like you’re just storing a number so you won’t hit this, but there’s a size limit as well, so don’t try to store full objects or anything. It’s designed for strings < 250 characters total.

 

@xavdid thanks! I was able to get it working!!

Two other things to note:

  • I also had to pass a string into the set() call. Passing a number would cause an error.
  • I had to put await before the get() and set() calls. It was obvious I should’ve needed that on the get call, but skipping it for the set() made the zap complete but not show the error caused by passing in a number.
Terms & Conditions