How I use n8n to make a personal RSS newsletter worth opening

I need to keep up with industry news and come up with content. Those jobs overlap, but finding something interesting isn't the same as having somewhere ready to write about it. My personal newsletter joins those two parts together.

I use RSS feeds, process the items with JavaScript in n8n and put the results into an HTML template. That gives me a newsletter made for me, from the sources I want to follow. When a story catches my attention, I press a button in the newsletter and n8n spins up a document so I can start writing.

That last bit is what makes the workflow interesting to me. I choose the story. The automation gets the document ready. Here's how the idea fits together, followed by a practical way to build your own version.

Start with the sources you would miss

RSS is a useful starting point because a publisher can expose a feed of its latest items. n8n's RSS Read node reads that feed from its URL. You can then work with the returned titles, links and whatever other fields the publisher supplies.

For a first version, pick a few sources you already read. A feed of everything vaguely related to your industry can become another inbox to avoid. Think about the decisions the reading helps you make: understanding a platform change, following a particular community or finding an issue you have something useful to say about.

Keep the publication name and original link attached to every item. They matter when you're deciding whether to read it, and again when you're writing. A headline on its own is rarely enough context. Some feeds contain only an excerpt, so follow through to the original article before treating the feed text as the full story.

You can start by running the workflow manually. Once the output is worth receiving, add a Schedule Trigger and choose a time that fits when you read. Check the workflow timezone as well as the clock time. Otherwise a perfectly valid schedule can still deliver the thing at the wrong point in your day.

Sources: n8n: RSS Read, n8n: Schedule Trigger.

Give JavaScript a small, boring job

In my setup, JavaScript sits between the RSS data and the HTML template. That processing step gives the items a form the newsletter can use. For a new build, n8n's Code node lets you do that work inside the workflow.

A sensible first job is to make each item consistent. Carry a title, source, original URL, publication date when supplied and a short excerpt. Don't invent a date when the feed omits it. A missing field should be something the template can handle, rather than a reason for an entire email to fail.

Then deal with repeats. Reading a feed twice will often return many of the same stories. Keep a record of items included in previous digests, using the feed's stable identifier where available, or a carefully chosen URL key. Removing duplicates within today's batch and remembering yesterday's batch are separate jobs. A fresh execution needs access to the saved record if it is going to recognise an old item.

Start with a plain list you can inspect. Check which entries were included and which were skipped before spending time styling the message. It is much easier to notice a duplicated headline in that list than to work backwards from a busy email after it has already arrived.

Sources: n8n: Code node.

Make an email you can actually skim

The HTML template is where those fields become something readable. n8n has an HTML node for generating a template from workflow data. Give each item a clear heading, the publication name, a short piece of context and a link to read the original. The newsletter should help you choose what deserves attention.

Keep the template modest enough to work on a phone. Long headlines should wrap, links should make sense without images, and the action for saving a writing idea should be easy to tell apart from the link to the source. Test a long title and an item with no description, not just the tidy sample you happened to use first.

Treat feed content as external input when putting it into HTML. Escape text fields and validate destination URLs; don't simply paste supplied markup into your template. n8n's HTML documentation flags the risks of untrusted input. You can get a perfectly readable digest from plain text excerpts without carrying somebody else's HTML into the message.

Connect your own email provider only when the preview looks right, and send the first attempts to an address you control. This is a newsletter for your reading, so you don't need audience segments, a campaign calendar or tracking pixels to make the first version useful.

Sources: n8n: HTML node.

The button that gives a story somewhere to go

This is the part I wanted beyond a list of links. If a story is interesting enough to write about, the button in my newsletter gets n8n to create a document for me. I can start working there instead of opening a fresh document separately.

For your own version, keep the document small at first. Give it a working title and the original story link, then leave room for your angle and anything you need to check. You could include prompts such as 'What do I think about this?' and 'What would my audience need explained?' The automation can prepare that space; you still have to decide what belongs in it.

Choose the destination you already use for writing. Google Docs is one supported option: n8n's Google Docs node can create and update documents. That is an implementation option, not a requirement to move your writing into a different app. Test access to the resulting document using the account you will actually write from.

Keep the original article linked in the draft, and distinguish the source's claims from your own notes. A prepared document is a starting point. It hasn't checked the reporting or decided whether your reaction is fair.

Sources: n8n: Google Docs.

Build the email action so a preview cannot fire it

There is a detail to handle carefully when building your own button. Email security tools and link previews may visit a URL before you click it. Opening a link should therefore display a confirmation page, without creating a document. Put the action behind an explicit confirmation that sends a POST request. GET requests are meant to retrieve information without causing that sort of change.

These are implementation recommendations for a new version of the workflow, rather than a description of every security detail in my existing setup. The landing page should identify the selected story, check that the request is authorised and give you a clear 'Create writing document' action. Keep provider credentials on the server. Use an authenticated session, or a short-lived signed link tied to that story, with server-side validation before the action is accepted.

Handle a double click as well. Save the relationship between a selected story and its created document so another press can return the existing document instead of producing a second copy. If creation times out, check whether the document already exists before retrying. Show a useful failure message when you can't confirm the result.

n8n's Webhook node supports different HTTP methods and authentication options, with separate test and production URLs. Use those deliberately. A long or obscure webhook URL on its own is not a substitute for checking who can ask it to do something.

Sources: n8n: Webhook, MDN: GET request method.

Try one complete trip before adding more feeds

Pick one feed, prepare a digest and send it to yourself. Read a source article, select the writing action and check the document it produces. That gives you one complete trip from incoming news to somewhere you can work, and shows which part needs attention next.

Then try a repeated story, an unavailable feed and a document service that refuses the request. The feed failing should be distinguishable from it having no new items. If the message send is uncertain, record that state before trying again. You don't want a retry filling your inbox with the same digest.

This is my personal reading workflow, separate from the AutomateNI mailing list. Building one does not sign anybody up for community updates. If you adapt the idea for a group, agree what they want to receive and who will look after it before adding recipients.

The smallest version is worth trying on its own. You get the sources you care about in one place, then a clear way to act on the story you chose. If you build a variation, I'd like to see what you put in the document and what you leave for yourself to figure out.

• Map your RSS-to-document workflow
• Share your version with AutomateNI

Sources and further reading

• n8n: RSS Read. Official feed-reading node documentation.
• n8n: Schedule Trigger. Official scheduling and timezone documentation.
• n8n: Code node. Official JavaScript processing documentation. The field and duplicate-handling choices here are suggested design decisions.
• n8n: HTML node. Official template-generation documentation, including the warning about untrusted input.
• n8n: Google Docs. One supported document destination, offered as an example rather than a claim about Callum’s provider.
• n8n: Webhook. Official methods, authentication and test/production URL documentation.
• MDN: GET request method. Explains why fetching a link should not create or change a resource. The confirmation and duplicate checks are build recommendations.

Continue with

• Email automation examples that do not turn you into a spam machine
• Document workflow automation: six jobs to stop doing by hand
• Task automation: start with the small job you keep putting off