@terbiy Just a thought but you could have an email template (I use a text expander service like textexpander.com - available on desktop and mobile devices) that triggers a new email search and does the workflow you're wanting.

The other thing you could do is have a webhook as the trigger step and bookmark that webhook URL in your browser (mobile and desktop) and each time you hit that URL it'll trigger the zap and show your browser a {success.....} message.

Those are the two ways off the top of my head that I would attempt to solve this problem. Please let me know if you opt for one of these or if neither of these will work for you in your situation, there are possibilities for alternative solutions.

Thank you, @PaulKortman!

Webhooks seem to be among your favourite techniques. I've created one in this case following your suggestion.

Unfortunately, nothing happens when I go to the desired URL. I got to this conclusion by looking at Zap History tab: nothing appeared there. Should this work as simple as pasting one in the address bar and hitting Enter?

@terbiy yeah I love webhooks (technically most of what is under the hood with Zapier is just webhooks anyways ;)

----

Well I'll be!

I just tested it and there's a glitch in the webhooks "catch webhook" that I didn't know about, perhaps @jesse or @Danvers could inform someone of this.

The glitch is that when you call a naked Webhook URL like https://hooks.zapier.com/hooks/catch/3489068/otz475x/ it will give you a success message but will not actually trigger the zap. A simple way to fix that is to add a "dummy" query string parameter like ?blue=1 so your URL/link/bookmark becomes https://hooks.zapier.com/hooks/catch/3489068/otz475x/?blue=1 and then it fires off the zap as it should.

You don't even need to use the querystring parameter at all within the Zap, just when you call the webhook it has to be there.

This works, thank you, @PaulKortman! Even merely adding `?go` at the end triggers the hook. A new problem arose, but it seems to be another topic.

@jesse / @Danvers - I'm curious, is the above issue actually a bug, or by design for some reason?

@terbiy Glad we got past this issue! Now onto the next! (It's how most of my Zapier/Workflow Automation jobs go... got this problem solved/tackled... here comes the next one!)

Good work on separating it to a new thread!

@PaulKortman and @AndrewJDavison_Luhhu looking at our help documentation, here is some information on the "Success" message for webhooks:

"For High Availability and High Throughput reasons - we always return a success message with a payload of debugging information when collecting a webhook - regardless of whether there is a Zap behind the webhook or if it is paused or not. The only way to know if a URL is live is to visit the editor and look at the URL (which never changes for a Zap). There is no way to customize the response to the request you send to the Catch Hook URL, as the response is sent before the Zap triggers and runs on the webhook request."

Help Article: https://zapier.com/help/create/code-webhooks/troubleshoot-webhooks-in-zapier

Does that help answer your question here?

@jesse That's good information to know, and I get why it has to be that way.

However, it doesn't make sense that a webhook trigger HAS to have a query string parameter at all. It should (imo) still trigger the zap even without a query string parameter (aka an empty payload).

Hey @PaulKortman I checked with a few folks on our support team and it looks like we have an open feature request for this, which we've added you to. We'll also update this thread if/when it's released.

Right now, we believe this is by design as we expect at least one parameter to be used in following Zap steps.

One of our support members has (unofficially) recommended an app called Lazy (https://www.lazy-app.com/) which they use to trigger off a couple of Zaps as well. The plain URL is simply an endpoint, the query is the payload in the GET request, so it likely doesn’t trigger off a blank value.

Hope this helps!

Thanks for the info @jesse I have been using Alfred which is more powerful (and more complex) but also can fire off a webhook if I needed to, and can pass info to the webhook.

But for me the problem is not about triggering the webhook, it's more about that the webhook needs a payload or query parameter, as you said it's assumed that is by design, but I see times where I don't need a parameter, or payload so that's why it "feels" like a bug instead of an intended behavior. Just my 2 cents. Thanks for putting me on the list!