Skip to main content

Hey folks, it’s Tim here from Premier Support with another Workflow for you!

If you’ve ever been trying to set up a Zap but you weren’t able to get the correct Sample Data pulled into the Trigger, I’ve recorded a 5 minute video to show how to work around this problem. You can watch it here:

 

To summarize the process in the video:

Create two Zaps:

Zap 1:

  • The Trigger you want to use
  • Webhooks by Zapier: POST Action

Zap 2:

  • Webhooks by Zapier Catch Hook Trigger

Then:

  • Copy the URL from Zap 2’s Trigger
  • Open the POST Action in Zap 1
  • Paste the URL from Zap 2’s Trigger into the URL field
  • Set the Payload Type field to Json
  • Turn Zap 1 on
  • Trigger Zap 1
  • Test Zap 2’s Trigger and you will see your Live Zap Equivalent Sample data pulled in.
  • Build the rest of your Zap in Zap 2.

When running Zap 2, Zap 1 must also be turned on.

The video ends there, but I wanted to mention one more advanced tip.

Once you’re sure you won’t need to edit Zap 2 for a while, you can replace the Catch Hook Trigger in Zap 2 with the Trigger you’re actually using in Zap 1 and run Zap 2 on its own because the values you mapped will have the same names. However, if you do need to make edits later on, you will need to change back to a Catch Hook Trigger and make sure that Zap 1 is still turned on and sending to the correct URL.

Let us know if you have any questions about this!

@Troy Tessalone 

You’re welcome, glad to help :)

I also wish this workaround wasn’t necessary. Almost all instances where there is a mismatch between Trigger and Live data or a static dummy record involve Triggers that fire when they receive Webhooks behind the scenes. The Zap Triggers from a Webhook, but the Sample usually needs to be pulled in via an API request. If there isn’t a corresponding API endpoint, or if the API request returns different data compared to a live Webhook, it creates this problem. Sometimes Webhook or API payloads may change over time from an app, causing something that used to match to have a mismatch, too.

It’s a difficult problem to solve, but something our product teams and engineers are looking into. We’ve received and logged many suggestions from users with our engineers to evaluate. This workaround is an adaption of one idea to pull in Trigger data from Zap Runs in Zap history.


Glad to hear you were able to make good use of Tim’s workaround here, @JamesApex27🤗

Sorry about the additional task usage that would be incurred with that workaround. To have an option to expose the raw JSON response with any app trigger would definitely be useful for folks! So I’ve passed your comments here over to the Product team for consideration. I can’t make any promises on whether that’s something that would definitely be built in the near future but we’ll be sure to let you know if it is! 


Just wanted to say this workaround is epic! Had been trying everything to pull through some data for a client and this solved my problem instantly!


@TimS 

Thanks for writing this up and sharing this advanced workaround for the issue!

I will be sure to give this a try.

Seems like there still is a missing quality check as part of the Zap approval process for Zap apps that only return a static dummy record (regardless of pulling thru recent records or testing with a new record to pull thru a sample to use) as that defeats the purpose for many folks of trying to use Zapier as a no-code tool.


Thanks for this Tim, it solved a problem I was having. However I do have two comments:-

 

  1. It increases our Zap usage
  2. A feature to expose the raw JSON from an integration step would solve this problem

Yay! That’s awesome news, @Lauravucic! Thanks so much for letting us know. Really pleased @TimS’s guide helped to get things sorted for you and your client! 😁🎉


Reply