bundle.meta.isLoadingSample
. When that is set to true
, the user is testing in the Zap editor, and your integration can respond with a limited payload. More on bundle.meta
properties here.
perform
method to build a deduplication table of records, so that the Zap will not run for existing records. The payload returned from this request must also be less than 20 MB.
bundle.meta
property that you can take advantage of here, bundle.meta.isPopulatingDedupe
. When set to true
, the Zap is being enabled, and you can use that to create a distinct request. The deduplication process only uses the id
property of each record, so one option to consider for this request is filtering the fields you return to reduce record size.
More on bundle.meta
properties here.
For those requests that might otherwise exceed timeout or size limits, you can make sure your filtered request is successful. Alternatively, if your filtered request has a lot of headroom in both time and size, you could instead use this to load more records into the Zap’s deduplication table than you usually request in your perform
. This is especially relevant for an API that might return an inadvertent older record in a later polling request.
Example: The Salesforce integration has an Updated Field on Record trigger that can trigger on older records that a user might not consider relevant for their running Zap. To help mitigate this, the integration uses a filtered request to download up to 104,000 records to the deduplication table during Zap startup.