I’m building a polling trigger for my Zapier integration that should fire when records get modified. The trigger works fine for new entries but completely ignores updates to existing ones.
My API returns data structured like this:
[
{ recordId: 100, name: 'Docker', created: '2021-12-03T10:30:15.820Z', lastModified: '2021-12-03T10:30:15.820Z' },
{ recordId: 101, name: 'Kubernetes', created: '2021-12-03T10:30:15.820Z', lastModified: '2021-12-03T10:35:20.820Z' },
]
Based on Zapier documentation, I need an updated_at field alongside the id for proper update detection. I’m mapping the lastModified value to updated_at but it still only catches new records.
Here’s my current implementation:
// required imports
const fetchRecords = async (z) => {
const data = await retrieveItems(z);
return data.map((item) => ({
...item,
updated_at: item.lastModified
}));
};
export default {
display: {
description: 'Fires when an item gets modified.',
label: 'Item Modified',
},
key: 'item_modified',
noun: 'Modified Item',
operation: {
outputFields: fieldDefinitions,
perform: fetchRecords,
sample: getExampleData(),
},
};
I could modify the ID to include timestamps but that would trigger on new records too, which isn’t what I want. What am I doing wrong here?
This is Zapier’s deduplication logic messing with you. I ran into the same thing - Zapier keeps an internal cache of record IDs it’s already processed. When you filter your API to only return modified records, Zapier loses track of the full dataset and can’t tell what’s an update vs. a new entry. Your code looks fine technically, but you need to return the full dataset (or at least recent records) on each poll. Let Zapier handle the filtering by comparing updated_at timestamps internally. Also double-check that your backend actually updates the lastModified field when records change. I’ve seen cases where certain update operations didn’t properly maintain that field. Once Zapier can see the complete picture across polling cycles, your trigger should work.
Had this exact issue last year and it drove me crazy for weeks. Your mapping’s fine - the real problem is Zapier’s polling system. It needs to see records in a specific way to tell new items from updated ones. When you only return modified records, Zapier thinks everything’s new since it hasn’t seen those record IDs in that polling cycle. Here’s what fixed it: make your API endpoint return ALL records (or at least recent ones) sorted by lastModified descending, not just the changed ones. Zapier compares updated_at timestamps against what it stored from the previous poll. Also check that your lastModified timestamps actually change when records get updated - our backend wasn’t updating that field properly for certain operations. The trigger fires when Zapier sees the same recordId with a newer updated_at timestamp.
zapier’s deduplication might be causing the issue. try adding type: 'polling' to your trigger config, and ensure you’re using iso strings for updated_at, not unix timestamps. also, keep an eye on your recordId – if it changes, zapier treats those as new records!