Skip to main content

Hey all,

We have a Zapier trigger for “contract_signed”.

When building a Zap, the test triggers are able to pull in 3 contracts as test data. However, as soon as one clicks “Load More”, an error, “We couldn’t find any more contracts” is thrown.

 

 

Taking a look at our Zapier app integration, we don’t have paging enabled for our trigger. So it looks like that might be the first step.

 

The docs also mention that `bundle.meta.page` should be used.

But where? In our Zapier scripting, we defined 2 functions for `get()` and plainGet()`

We also have a variable defined as `var Zap` where we define `post_subscribe()`, `pre_unsubscribe()` and other get methods that utilize the 2 previously defined ‘get/plainGet’ methods. (e.g. `get_client: function(bundle) {return get("clients", bundle)}`

 

Would we need to add the `bundle.meta.page` under our get/plainGet methods, like so?

function get(resourceName, bundle) {
var resource = z.JSON.parse(z.request({
method: 'GET',
url: baseURL + '/' + resourceName + '/' + bundle._id,
headers: {
"Authorization": bundle.auth_fields.api_key
},
params:{'page': bundle.meta.page +1}
}).content) || {};
delete resource.id;
return resource;
}

 

cc: @ikbelkirasan, @CraigNet3 


@Dubsado the “Load More” is powered by the performList function in the trigger code. More info here: https://platform.zapier.com/cli_tutorials/resthooks#step-4-write-the-performlist-function

Typically the performList code is configured to return an array of the latest data from your API that matches the records triggering the Zap. From that API call Zapier will only return the first 3 objects in the array, which is what you see in the test trigger results. The assumption is that the first 3 objects are the latest objects in the array.

However these 3 objects will then be deduped by Zapier. If any of the 3 objects have already been sent to the trigger in that Zap, then Zapier will not return them. It will only return new records never sent to that trigger in the Zap you are setting up.

To see new entries in the test trigger section for that Zap, you’ll need to add new records in the external system the performList calls, then click “Load More” again for it to perform the API call to pull them in.

Paging would not be needed for the most part unless the API you are using in the performList returns old data first (ascending or chronological vs descending or reverse chronological), or doesn’t provide a sorting option.

I hope that helps.


@Dubsado the “Load More” is powered by the performList function in the trigger code. More info here: https://platform.zapier.com/cli_tutorials/resthooks#step-4-write-the-performlist-function

Typically the performList code is configured to return an array of the latest data from your API that matches the records triggering the Zap. From that API call Zapier will only return the first 3 objects in the array, which is what you see in the test trigger results. The assumption is that the first 3 objects are the latest objects in the array.

However these 3 objects will then be deduped by Zapier. If any of the 3 objects have already been sent to the trigger in that Zap, then Zapier will not return them. It will only return new records never sent to that trigger in the Zap you are setting up.

To see new entries in the test trigger section for that Zap, you’ll need to add new records in the external system the performList calls, then click “Load More” again for it to perform the API call to pull them in.

Paging would not be needed for the most part unless the API you are using in the performList returns old data first (ascending or chronological vs descending or reverse chronological), or doesn’t provide a sorting option.

I hope that helps.

 

@CraigNet3 Is this in reference to the new CLI? We’re currently still using the legacy web builder. Would the performList code still be valid?


@Dubsado it applies to both if you are using a REST hook for the trigger. In the Visual Web Builder you should see a section called “Perform List”. If you are instead using a polling trigger then it would be the API Endpoint section that would provide data for both live running and test trigger data.