News to social posts pipeline

I handle it in two layers. At ingestion, a Code node normalises each item by stripping tracking parameters from the URL and lowercasing the host, then hashes the URL together with the title. I insert that hash into a Postgres table with a unique constraint using ON CONFLICT DO NOTHING, and only rows that were actually inserted continue. Because this is atomic in the database, it is safe even when several queue-mode workers run at once. At publish time, I check publish_log for that hash and channel before calling the API, and I write the post ID right after. So if retry-on-fail fires after a timeout, or someone replays an execution, it sees the post already exists and skips it.

A Schedule Trigger fires on a cron interval. RSS Read nodes, either one per feed or a Loop Over Items over a list of feed URLs, fetch the latest items, and a Merge node combines them. A Code node normalises each item by canonicalising the URL and trimming the title, then hashes it. A Postgres insert with ON CONFLICT DO NOTHING returns only new rows. For each new item, a Basic LLM Chain calls a model through Vercel AI Gateway and returns structured JSON with one draft per channel. Slack send-and-wait pauses the execution for review. A Switch routes approve, edit or reject. HTTP Request nodes publish with OAuth credentials and the item hash. publish_log records every outcome, and an Error Trigger workflow sends alerts.

Publishing is only reachable through one path: the approve or edit branch of the Switch node that follows Slack send-and-wait. The reject, timeout and default branches all lead to logging and never to an HTTP Request publish node. The Error Trigger workflow only sends alerts and holds no publish credentials or nodes. I also check that the response came from an authorised approver before the Switch treats it as approval. Every publish row in publish_log records the approver and the decision, so an audit can confirm that each live post has an approval. In code review I treat any new edge into a publish node from outside the approval branch as a blocking defect.

This is the classic ambiguous failure, because a timeout does not tell you whether the post succeeded. Each request carries the item hash. Where the platform supports an idempotency key or client reference, the hash goes there, so the platform rejects or merges the repeat. Where it does not, I check publish_log for a row with the same item hash and channel and a platform post ID before sending. I can also query the platform for recent posts that contain the source link. A unique constraint on item hash and channel in publish_log means a second successful write fails loudly instead of silently recording a duplicate. Retries are bounded and spaced out, not unlimited.

With a bare insert-and-forget design, yes. The insert claims the hash, so future runs will treat the story as seen and skip it. To fix that, I add a status column to the items table with values such as new, drafted, pending_approval, published, rejected, timed_out and failed. The Error Trigger alert links to the execution, and failed rows can be reprocessed by a small recovery workflow that picks up items stuck in new or failed beyond a threshold. The claim still prevents duplicates, because recovery works on existing rows and does not re-insert them. That gives you exactly-one claim without at-most-once loss.

Model summaries can get facts or tone wrong, and a bad post on a brand account is hard to undo, so a person signs off before anything goes public. To keep it fast, I use the Slack node's send-and-wait operation, which pauses the execution and persists it, so it uses no worker capacity while it waits. Each story gets its own message, sent through Loop Over Items, so one slow decision doesn't hold up the others. The editor can approve, reject or edit the text inline. I also set a timeout so that old news expires and is logged as rejected rather than published late. Edit rates per channel tell me where the prompt needs work.

In n8n it's simply an OpenAI-compatible chat model node with the base URL set to https://ai-gateway.vercel.sh/v1 and one AI Gateway API key. That key reaches many providers, so I can try anthropic/claude-sonnet-4.5 against openai/gpt-5 by changing a model string rather than adding new credentials. The gateway handles fallbacks if a provider is down and gives me spend tracking per workflow. No provider keys live in n8n, which shrinks the blast radius if the instance is ever compromised. For a content pipeline where quality and cost per post both matter, being able to switch models cheaply is worth a lot.

Feeds often add tracking parameters such as utm_source, switch between http and https, or add trailing slashes. Feeds and syndication partners can also republish the same link with small changes. If you hash raw values, the same story produces different hashes and gets posted twice. The Code node builds a canonical URL by removing tracking parameters, lowercasing the host and stripping fragments, and it trims the title. The hash is usually built mainly from the canonical URL, because titles get edited after publication. If you include the title, a headline correction looks like a new story. I would hash the canonical URL, keep the title as metadata, and document the rule so it stays consistent across versions.

I would use two core tables. The items table has a hash as its unique primary key, plus canonical_url, title, feed_source, first_seen_at, a status field and an updated_at column. The publish_log table has an id, item_hash as a foreign key, channel, final_text, approver, decision (approved, edited, rejected or timed_out), platform_post_id, requested_at, published_at and an error field. A partial unique index on (item_hash, channel) where the post was published enforces one live post per story per channel. Indexes on status and first_seen_at support recovery jobs. Drafts can be stored on a separate table, so you can compare model output with the final edited text.

Send-and-wait is configured with a time limit. When the limit passes, the execution resumes on a timeout path, and that path must never lead to publishing. The item is logged in publish_log with decision timed_out and its status is updated. Older news loses value quickly, so I would usually let it expire rather than auto-publish it. If the team wants a second chance, a reminder in Slack or a re-queue for a later review is acceptable, but it still needs an explicit approval. The timeout length is a product decision based on how quickly the news goes stale and how many reviewers are on shift.

Downstream nodes need to pick out each channel's draft reliably. Structured output with a fixed schema, such as one field per channel plus the source link, lets the Switch and HTTP Request nodes reference fields directly instead of parsing prose. I validate the output against the schema in a Code node or a structured output parser. That check covers required channels, length limits and whether the source URL matches the input item. If validation fails, I retry once and then send the item to the error path. Validation also catches the model inventing a different link, which matters because a wrong source link is a credibility problem.

Drafting posts is a single, predictable transformation: article in, drafts out. It needs no tools, no multi-step reasoning and no memory. A Basic LLM Chain makes one model call with a fixed prompt, so it is cheaper, faster and easier to test. An agent decides which tools to call, and here that only adds variability and attack surface, especially because the input is untrusted feed content. If you later need the model to fetch the full article or check facts, you could add a tool. Even then, I would keep it narrow and read-only, and never give the model a publishing tool.

Feed text is untrusted input, so an article can contain instructions aimed at the model. The model has no tools and no publishing ability, so the worst it can do is write a bad draft. In the prompt, I wrap the article in clear delimiters and tell the model to treat it as data only. The output is validated against the schema, and I check that the source link matches the item's canonical URL. Most importantly, a human reads every draft before anything goes out. I would also strip HTML and limit input length, which reduces both injection surface and token cost.

Posting to a review channel is not enough on its own, because anyone in that channel could click approve. After send-and-wait resumes, I check the responding Slack user ID against an allowlist of editors before the Switch treats the response as approval. That allowlist can live in Postgres or in a Set node managed through config. An unauthorised response is logged and does not count as approval. The review channel itself should be private, with controlled membership. The approver's ID goes into publish_log, so every live post can be traced to a named person.

Each channel is an independent publish with its own row in publish_log, keyed on item hash and channel. If LinkedIn fails after X succeeds, X's row records a platform post ID and LinkedIn's row records the error. A retry must target only the failed channel, so the retry logic checks publish_log first and skips channels that already have a post ID. That way a re-run never reposts to X. The Error Trigger alerts the team with the execution link. I would not try to roll back the successful post automatically, because deleting a live post is a human decision.

It is a separate workflow that starts when a linked execution fails, whether from a model call, a publish request or Slack. It posts an alert to a team Slack channel with the workflow name, the failed node, the error message and a link to the execution, so someone can inspect it or retry it. It must never publish, because it runs outside the approval path. A publish from there could send a draft no one approved, or repeat a post that may already have gone live. Recovery happens through deliberate human action or through the normal approval-gated path.

It can be, provided every side effect is idempotent. The dedup insert uses ON CONFLICT DO NOTHING, so a replay does not create a new item. However, a replay that starts from the beginning may then return no rows and stop, which is safe but does nothing. Publishing is the dangerous step. Because each request carries the item hash and checks publish_log for an existing post ID on that channel, a replay skips channels that already succeeded. The replay also must not skip approval, so I would only replay executions whose approval is recorded.

Not with exact hashing. The hash dedups the same canonical link, not the same event. For many teams that is acceptable, because the editor rejects the second item in Slack. If duplicates become noisy, I would add a second layer: compare the new title, or an embedding of the title and summary, against recent items using a similarity threshold. Close matches get flagged in the Slack message as possible duplicates rather than dropped automatically. Similarity is fuzzy and false positives would hide real stories, so the human stays in the loop for that decision.

The AI Gateway API key, the Slack token, the Postgres credentials and each platform's OAuth credentials are stored in n8n's encrypted credential store. Nodes reference them and never hardcode them. Because models go through AI Gateway, no provider keys exist in n8n at all, and one key can be rotated centrally. On self-hosted n8n, the encryption key must be kept secret and backed up, and the editor UI should be limited to a small group. OAuth scopes should allow posting only, and I would use dedicated service accounts so that revoking access does not affect anyone's personal account.

I would work from stated assumptions rather than guess. Suppose there are 30 feeds polled every 15 minutes, each returning about 20 recent items. That is about 600 items fetched per run, but after dedup perhaps only a handful are new. The fetch volume is trivial. The model calls scale with new items, not fetched items. The real ceiling is human review: if editors can review a limited number of stories per hour, that sets throughput. Waiting executions are persisted and use no worker capacity, so pending approvals are cheap. A single n8n instance handles this easily. Queue mode matters only when feeds or new-item volume grow a lot.

Queue mode separates the main instance from workers. It uses Redis to distribute executions across several worker processes. I would move when executions start queuing behind each other: for example, many feeds, frequent schedules, long model calls, or other workflows sharing the instance. Because dedup relies on an atomic Postgres insert, running on several workers stays safe and two workers cannot claim the same hash. Before moving, I would confirm that Postgres, not SQLite, is the n8n database, that Redis is reliable, and that each worker can reach the credentials and network endpoints it needs.

Very little, by design. Both runs fetch overlapping items, but only one insert per hash can succeed, because the unique constraint with ON CONFLICT DO NOTHING is atomic. Each item is therefore claimed by exactly one execution. The main costs are wasted fetches and possibly more pending approvals at once. If overlap happens often, I would lengthen the interval, reduce the number of items fetched per feed, or move drafting into a sub-workflow so the main run finishes quickly. I would also monitor execution duration, so slow feeds or slow model responses show up before they pile up.

One bad feed must not stop the others. I set a timeout on each RSS Read node, enable retry-on-fail with a small number of attempts, and configure the node to continue on error, so the Merge still receives the other feeds. Failures are logged with the feed URL. If a feed fails repeatedly, a Slack alert tells someone to check it. Malformed items, such as ones missing a link, are filtered out in the normalisation Code node before hashing, because a hash of an empty URL would collide and block real items.

Cost scales with new items, so dedup before drafting is the biggest saving, because the model never sees stories we have already seen. I send a trimmed title and summary instead of full article HTML, and I cap output length per channel. All drafts come from one call that returns structured JSON, not one call per channel. AI Gateway provides spend tracking across providers, so I can watch cost per day and per model. If quality allows, a cheaper model can handle the drafting. Optionally, a relevance filter before drafting can drop off-topic items.

Requests go through Vercel AI Gateway, so I can configure fallbacks to another provider's model without changing credentials in n8n. The model is just a string such as anthropic/claude-sonnet-4.5 or openai/gpt-5. In n8n, the chat model node also has retry-on-fail for transient errors. If everything fails, the Error Trigger alerts the team, and the item stays in a failed status so the recovery job can draft it later. Outputs from a fallback model still go through schema validation and human review, so a quality difference cannot reach a live channel unnoticed.

I would monitor execution success and failure counts from n8n's execution log, along with Error Trigger alert volume. From Postgres: new items per run, items stuck in each status, approval rate, edit rate, rejection rate, timeout rate and time-to-approve. From publishing: success rate per channel and retry counts. Spend comes from AI Gateway. A high edit or rejection rate means the prompt or channel rules need work. A rising timeout rate means review capacity is the bottleneck. Items stuck in new or failed indicate silent losses that the recovery job should be clearing.

Dedup has to be atomic. Postgres gives you a unique constraint and INSERT ... ON CONFLICT DO NOTHING RETURNING, so the database itself decides who wins when two executions see the same item. A sheet has no unique constraint, so you would have to read, check and append, which races under concurrency and in queue mode. Sheets also has API rate limits and becomes slow and fragile as rows grow. Postgres also hosts publish_log with proper indexes and constraints. A sheet could be a read-only reporting view, but it should not be the source of truth.

When the Switch routes to the edit branch, a Set or Code node replaces the model draft with the editor's text for each edited channel before any publish node runs. Then I re-check platform limits, such as maximum length, because a human can exceed them too. If an edit breaks a limit, I post back to Slack instead of truncating silently. publish_log stores the final published text, not the draft, along with decision edited. Keeping the original draft separately lets you measure how much editors change and improve the prompt.

First, I would move the main workflow to just fetching, normalising and claiming items, and hand each new item to a sub-workflow through Execute Workflow so long model calls and waits do not block the schedule. I would turn on queue mode with Redis and several workers. I would add a relevance filter or classifier before drafting, so editors only see stories worth reviewing, because human review becomes the bottleneck long before n8n does. I would also add near-duplicate detection across outlets, and index first_seen_at so the items table stays fast.

I keep them as data, not inside the prompt text. A config table or a Set node holds each channel's name, maximum length, tone guidance, hashtag policy and whether to include the link. The prompt is assembled from that config, and the same config drives validation after the model responds and after edits. Changing a rule then means changing one place, and the rule the model was told matches the rule we enforce. Versioning the config lets you see which rules produced a given post.

I would add the channel to the config with its length and tone rules, and extend the structured output schema so the model returns a draft for it. I would also add a field for it to the Slack review message. Then I would create an n8n OAuth credential with posting-only scope, add an HTTP Request publish node with retry-on-fail that carries the item hash, and log results to publish_log under the new channel name. The partial unique index on item hash and channel already covers it. I would test with a sandbox or private account first.

The content is public news, but the workflow still stores personal data. Approver Slack IDs and names are in publish_log, and OAuth tokens give access to company accounts. I keep logs to what an audit needs, set a retention period for execution data in n8n because executions can contain full payloads, and restrict database and editor access. Article content sent to models goes through AI Gateway to the chosen provider, so I check the provider's data-use terms. Indian teams should also check their obligations under the Digital Personal Data Protection Act for any personal data they store.

I would use a test feed with known items, including duplicates that differ only by tracking parameters, to confirm that normalisation and dedup work. Pinned data on nodes lets me test the LLM chain and validation without refetching feeds. Publishing points to sandbox or private accounts. I would test each Switch branch: approve, edit, reject, timeout and an unauthorised approver. I would simulate failures, such as a model error, a publish timeout or a partial channel failure, and confirm alerts fire and no duplicate or unapproved post appears. Replaying an execution should produce no new posts.

1. AOnly the rows that conflicted
2. BThe total row count of the table
3. CEvery row that was attempted
4. DOnly the rows that were newly insertedCorrect answer

Why: Rows that hit the conflict are skipped and not returned, so only new items continue.

1. ATo make URLs work in Slack
2. BBecause RSS forbids query strings
3. CTo shorten the post text
4. DSo the same story with different utm parameters produces the same hashCorrect answer

Why: Canonicalising the URL stops variants of the same link from looking like new stories.

1. ACarrying the item hash and checking publish_log or an idempotency key before re-sendingCorrect answer
2. BIncreasing the timeout to unlimited
3. CRe-running the dedup insert
4. DDisabling all retries

Why: The hash lets the workflow recognise a repeat send and skip it, rather than create a second post.

1. AStore seen GUIDs in workflow static data
2. BInsert a normalised URL hash into Postgres with a unique constraint and continue only on successful insertCorrect answer
3. CCompare items to the previous execution's output with a Merge node
4. DSort items by date and keep only those newer than the Schedule Trigger's last run

Why: A unique constraint makes the check-and-insert atomic across concurrent workers and survives restarts. Static data and comparisons with the last execution are not reliable under concurrency or when feeds republish items.

1. AUse the OpenAI-compatible chat model with base URL https://ai-gateway.vercel.sh/v1 and an AI Gateway API keyCorrect answer
2. BCall the gateway with a Webhook node
3. CSet the model name to vercel/gateway in the Anthropic node
4. DInstall a dedicated Vercel community node and add each provider's key

Why: AI Gateway exposes an OpenAI-compatible API, so the OpenAI-compatible chat model node only needs the gateway base URL and key. Models are then selected by names like anthropic/claude-sonnet-4.5.

1. AChat Trigger
2. BError Trigger
3. CWebhook
4. DSchedule TriggerCorrect answer

Why: The workflow polls feeds on a cron interval, so a Schedule Trigger starts it.

1. AMerge
2. BSwitchCorrect answer
3. CLoop Over Items
4. DSet

Why: A Switch node sends each decision value to its own branch.

1. AGet channel history
2. BSend message
3. CSend and wait for responseCorrect answer
4. DUpdate message

Why: Send-and-wait posts the message and pauses the execution until a response arrives.

1. ABasic LLM Chain with an OpenAI Chat Model sub-node pointed at AI GatewayCorrect answer
2. BText Classifier
3. CSummarisation node calling each provider directly
4. DAI Agent with a publishing tool

Why: Step 3 specifies a Basic LLM Chain using an OpenAI Chat Model sub-node configured for AI Gateway.

1. APublish a postCorrect answer
2. BRead the error message
3. CSend a Slack alert
4. DInclude an execution link

Why: It runs outside the approval path, so it may alert but must never publish.

1. ALog it as timed out and do not publishCorrect answer
2. BDelete the item from the dedup table
3. CRetry the model call
4. DPublish the model draft automatically

Why: Nothing unapproved may be published, and timed-out approvals are logged.

1. Aplatform_post_id alone
2. B(item_hash, channel) for published rowsCorrect answer
3. Capprover
4. Dtimestamp

Why: A unique index on hash and channel allows one live post per story per channel.

1. AOnly one insert succeeds, so only one execution processes itCorrect answer
2. BPostgres throws and both runs fail
3. CThe second run deletes the first claim
4. DBoth draft and send it for approval

Why: The atomic unique-constraint insert lets exactly one execution claim each hash.

1. AIt will be posted twice
2. BIt is silently lost, because future runs treat it as seenCorrect answer
3. CPostgres rolls back the whole table
4. DSlack approves it automatically

Why: The claim marks the item as seen, so it needs a status column and a recovery process to be retried.

1. ARemoving the Slack step
2. BHashing the article body
3. CUsing a larger model
4. DHuman approval of every post, a model with no tools, and output validationCorrect answer

Why: Untrusted input cannot publish anything on its own when the model has no tools and a human reviews every output.

1. ARetry only LinkedIn, skipping channels that already have a post ID in publish_logCorrect answer
2. BDelete the X post first
3. CMark the whole item as rejected
4. DRepublish to both channels

Why: Per-channel logging keyed on hash and channel makes retries target only the failed channel.

1. AUse a public channel
2. BTrust anyone in the channel
3. CCheck the responder's Slack user ID against an allowlist before treating the response as approvalCorrect answer
4. DAsk the model to verify the user

Why: An explicit allowlist check makes approval mean approval by an authorised editor.

1. AIt fails and must be retried manually
2. BIt is paused and persisted, then resumes when the response arrives or the timeout expiresCorrect answer
3. CIt publishes immediately and lets the editor delete the post later
4. DIt keeps a worker busy, polling Slack

Why: Wait-style operations put the execution into a waiting state that is stored in the database. The execution resumes on the response or timeout, without tying up a worker in the meantime.

1. AMergeCorrect answer
2. BWait
3. CSwitch
4. DIF

Why: The Merge node combines items from several inputs into one stream.

1. AOnly by a numeric model ID
2. BBy the provider's API key
3. CBy the n8n node name
4. Dprovider/model, for example anthropic/claude-sonnet-4.5Correct answer

Why: AI Gateway uses provider-prefixed model strings such as anthropic/claude-sonnet-4.5 or openai/gpt-5.

1. AChains are the only nodes that support AI Gateway
2. BAgents cannot run on a schedule
3. CAgents cannot return JSON
4. DDrafting is a single step with no tools needed, so a chain is simpler and more predictableCorrect answer

Why: Drafting needs no tool use or reasoning loop, so a single chain call is cheaper, easier to test and has less attack surface.

1. ABoth versions
2. BA new model draft generated from the edit
3. CThe original model draft
4. DThe edited text, which replaces the draft before publishingCorrect answer

Why: Step 5 states that edited text replaces the model draft before anything is published.

1. AQueue mode with Redis and workersCorrect answer
2. BAdding more Merge nodes
3. CUsing SQLite
4. DRunning several editor UIs

Why: Queue mode uses Redis to distribute executions to worker processes.

1. APostgres publish_log
2. BSlack
3. CThe RSS Read node
4. DVercel AI GatewayCorrect answer

Why: AI Gateway tracks spend across providers behind a single key.

1. AMerges the posts
2. BBlocks both stories
3. CCatches it automatically
4. DTreats them as two different items; catching them needs similarity checks or editor reviewCorrect answer

Why: Exact hashes match identical canonical links, not the same event reported at different links.

1. APostgres supports unique constraints and atomic upserts, so dedup is safe under concurrencyCorrect answer
2. BSheets is not supported by n8n
3. CPostgres is required for Slack
4. DSheets cannot store text

Why: Read-check-append on a sheet races, while a unique constraint makes the database decide atomically.

1. ADownstream nodes can reliably reference and validate each channel's draftCorrect answer
2. BSlack only accepts JSON
3. CRSS requires JSON
4. DJSON is cheaper per token

Why: A fixed schema lets publish and validation nodes read fields directly instead of parsing prose.

1. AIn the Slack review message
2. BIn publish_log
3. CHardcoded in the HTTP Request URL
4. DIn n8n's encrypted credential store, referenced by nodesCorrect answer

Why: n8n stores credentials encrypted and nodes reference them, so secrets never appear in workflow data.

1. AIn the RSS Read node's cache
2. BIn an in-memory variable in a Code node
3. CIn the database through a unique constraintCorrect answer
4. DIn the Slack channel

Why: Only a shared, atomic store like a Postgres unique constraint is consistent across separate worker processes.

1. ARetrying failed posts
2. BMerging Slack replies
3. CApproving drafts one at a time
4. DIterating over a list of feed URLs in batchesCorrect answer

Why: It processes the list of feed URLs in batches as an alternative to one RSS Read node per feed.

1. AOnly SQL
2. BOnly Go
3. CBash only
4. DJavaScript or PythonCorrect answer

Why: The Code node supports JavaScript and Python.

1. AOnly on Vercel
2. BOnly as a desktop app
3. CSelf-hosted or on n8n CloudCorrect answer
4. DOnly inside Slack

Why: n8n is fair-code and can be self-hosted or used through n8n Cloud.

1. AFinal text
2. BApprover
3. CPlatform post ID
4. DEditor's Slack passwordCorrect answer

Why: publish_log records the hash, channel, final text, approver, decision, post ID and timestamps, never passwords.