n8n RSS Feed Exercise: Build a Digest That Survives Repeat Runs
An editorial n8n RSS feed exercise for practising persistent entry state, email retries, sequential tests and maintenance ownership.
Checked against the cited sources on .
Editorial exercise: define your n8n RSS feed digest
Build an n8n RSS feed workflow that discovers entries, stores a digest before sending it and remembers delivery state between sequential runs. This is an editorial exercise using documented capabilities; the proposed workflow has not been executed or validated.
You need an n8n environment with the nodes described below, a reachable public feed, project Data Table access, provider-configured SMTP credentials and a test recipient. n8n documents RSS Read for reading a publication URL and Send Email for SMTP delivery. Some providers require additional SMTP setup or an app password.
Confirm node availability before starting: the supplied documentation generally specifies no version, edition or plan. Keep this exercise to one feed and sequential runs; concurrent processing, atomic uniqueness, transactional delivery and production-scale operation are excluded.
Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.rssfeedread.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.sendemail.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/integrations/builtin/credentials/send-email/README.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.datatable/rows.md at main · n8n-io/n8n-docs · GitHub
Prepare stable keys and separate state
n8n documents Data Tables as persistent project storage and supports conditional row retrieval, insertion and updates. They suit light to moderate storage; project members can access project tables by default, and direct Code-node access is unsupported. The following schemas and fixtures are editorial suggestions.
Create an entries table with feedKey, entryKey, title, link and digestId. Treat feedKey plus entryKey as the identity, enforced through sequential lookup and insertion. Create a deliveries table with digestId, entryKeys, renderedBody, status and lastError. We think separating discovery from delivery makes the retry decision easier to inspect.
Choose a stable identifier available in your feed, with an explicit fallback policy; reject entries without an acceptable key. Do not use array position or publication time alone. Use these fictional fixtures, where each letter retains the same title and link across runs.
| feedKey | entryKey | title | link |
|---|---|---|---|
| practice-feed | A | Alpha update | Stable article link A |
| practice-feed | B | Beta update | Stable article link B |
| practice-feed | C | Gamma update | Stable article link C |
Sources: n8n-docs/docs/build/work-with-data/data-tables.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.datatable/README.md at main · n8n-io/n8n-docs · GitHub, skills/skills/n8n-data-tables-official/references/DEDUP_PATTERNS.md at main · n8n-io/skills · GitHub
Suggested solution: schedule, persist and send
For scheduling, the vendor FlowKit's 2026 guide describes Schedule Trigger followed by RSS Read, and cautions that returned feed fields vary. This design uses that scheduled pattern rather than an n8n RSS Feed Trigger node. Exact scheduling configuration, timezone settings and publication controls are outside this exercise.
Follow this suggested sequence. Data Table operations support the state transitions, Aggregate can collect item data into one list, and Send Email supplies SMTP delivery. Aggregation itself neither formats nor sends the message.
For this n8n RSS feed exercise, our suggested routing design uses separate scheduled discovery and delivery workflows, run sequentially without overlap. Start the delivery workflow directly from its own Schedule Trigger and query pending deliveries, without passing through RSS Read or depending on discovery output. This editorial choice keeps stored deliveries reachable when the feed fetch fails or discovery produces no items.
- Connect Schedule Trigger to RSS Read and map the feed's available fields to the fixture shape.
- Look up each compound entry key. Enable Always Output Data on the empty Get lookup, branch explicitly and insert only undiscovered entries; keep branch output shapes consistent.
- Retrieve entries without a digestId. Use Aggregate's All Item Data option to retain feedKey, entryKey, title and link together in each list item, then render a plain-text email body.
- Persist a pending delivery with its digestId, entry keys and renderedBody; associate those entries with that digestId before sending.
- In the separate scheduled delivery workflow, query deliveries whose status is pending. Stop without sending if none exist; otherwise use each delivery's stored payload.
- Configure Send Email with your SMTP credential, the Send operation, an authorized sender address, your test recipient, a subject such as Practice RSS digest, and Text format. Map its message body to the pending delivery's stored renderedBody.
- After successful Send Email completion, update that digestId's delivery to sent. Route send failures through the error output, retaining pending status and recording lastError.
Sources: n8n RSS Read & RSS Feed Trigger node documentation | FlowKit, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.datatable/README.md at main · n8n-io/n8n-docs · GitHub, skills/skills/n8n-data-tables-official/references/DEDUP_PATTERNS.md at main · n8n-io/skills · GitHub, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.datatable/rows.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.aggregate.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.sendemail.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/build/understand-workflows/workflow-components/work-with-nodes.md at main · n8n-io/n8n-docs · GitHub
Test sequential repeat runs and inspect failures
Run the following suggested checks and record actual results. Here, sent means successful Send Email node completion, not confirmed inbox receipt. A stored pending payload should remain available even if its entries disappear from the feed.
| Test input | Required observation |
|---|---|
| First run: A/B | One digest containing A and B |
| Next run: B/A | No additional delivery |
| Next run: B/C/A | Next digest contains only C |
| Fixture with no acceptable identity key | Rejected without inserting an entry or sending it |
| New entry; intentionally fail SMTP | Queryable pending delivery and recorded error |
| Restore credentials; omit entry from feed | Later attempt uses the stored payload |
| Intentionally fail RSS Read with a delivery pending | Inspect the fetch error route; existing state remains unchanged |
| After failed fetch, run delivery workflow independently | Existing pending delivery remains retryable from its stored payload |
For missing entries, inspect empty Get output, branch shapes and stored keys. Always Output Data belongs on the lookup here; n8n warns that using it on IF nodes can create infinite loops. Use Continue using error output for explicit failure routing; Continue instead passes the last valid data.
Assign an error workflow for otherwise unhandled failures. n8n's guidance says handled node errors do not automatically trigger it. Programmatic error-workflow assignment is documented for n8n 2.29.0+; older instances use workflow settings.
Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.datatable/README.md at main · n8n-io/n8n-docs · GitHub, skills/skills/n8n-data-tables-official/references/DEDUP_PATTERNS.md at main · n8n-io/skills · GitHub, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.sendemail.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/build/understand-workflows/workflow-components/work-with-nodes.md at main · n8n-io/n8n-docs · GitHub, skills/skills/n8n-error-handling-official/references/ERROR_WORKFLOWS.md at main · n8n-io/skills · GitHub
Reflect on uncertain delivery and assign owners
Suggested reflection: SMTP accepts the message, but the sent-state update fails. Explain why retrying could duplicate mail, then document who decides whether to resend or reconcile the record. The supplied sources establish neither exactly-once SMTP delivery nor atomic coordination between sending and state updates.
In our view, an uncertain send needs a named decision-maker before unattended use. Complete this editorial handover checklist alongside your recorded test results.
Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.datatable/README.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.sendemail.md at main · n8n-io/n8n-docs · GitHub
