n8n Remove Duplicates node: skip repeat rows before Sume calls

Put n8n's Remove Duplicates node in front of the Sume submit step, set to Remove Items Processed in Previous Executions with Keep Items Where set to Value Is New, and dedupe on a stable id such as your row id. Then a repeated row, or a sheet that is re-read on every schedule run, never becomes a second paid job. It is a different safeguard from Sume's Idempotency-Key, which only protects a retry of the same submit; use both.

The node's behavior comes from n8n's Remove Duplicates page (read 2026-10-02); Sume's retry rule from Jobs and results.

What can the node compare against?

It has three operations. Remove Items Repeated Within Current Input compares items in one run, across all fields or selected fields. Remove Items Processed in Previous Executions compares against items seen in earlier executions. Clear Deduplication History wipes that memory. For the second operation, Keep Items Where can be Value Is New, Value Is Higher than Any Previous Value, or Value Is a Date Later than Any Previous Date.

Why is a node needed if Sume has an Idempotency-Key?

The key and the node stop different mistakes. Sume's docs say to send Idempotency-Key when retrying after client-side timeouts or network failures, and to reuse the same key only for the same operation and payload: a retry then returns the original job. It does not know that two different spreadsheet rows, or the same row read on two schedule runs, describe one intended video unless you give both the same key.

So derive the key from the same stable id you dedupe on, for example row-<id>-v1. The submit schema accepts 1 to 255 printable ASCII characters. Then a repeat that slips past the node still resolves to the original job.

Where does the node sit, and what should I test?

Place it directly before the HTTP Request node that submits. n8n's page says the node compares against items from previous executions, but it does not say what happens to an item's history entry if a later node fails. Test that before you rely on it: run a row, force the Sume call to fail, then run again. If the failed row is skipped, add a retry path or use Clear Deduplication History for that case.

Pair this with the Retry On Fail setting, which also needs the same key on every attempt, and with Loop Over Items when a sheet holds many rows.

What about a ledger bigger than the history size?

The page describes History Size as the number of items n8n stores, 10,000 by default, and does not say which entries go first once it is exceeded. For a large sheet, write the Sume job id back into a column and filter on an empty cell instead, or keep a table of row ids and job ids and check it before each submit. That table is also where you read results later.