Content syndication done manually is a tax on every piece you publish. Write the post, push it to WordPress, then open Medium and paste the content, set the canonical URL, format the headers, and submit. Then do the same for Substack. Then LinkedIn. Then Dev.to. None of these steps are hard. All of them compound, every post, every platform, every time. At some point the accumulated cost of manual n8n content syndication automation work exceeds what it would take to build something that handles it. That crossover happened faster than expected.
EchoCast is the syndication layer built on top of an existing n8n and Playwright stack. This post covers what it is, how the architecture is structured, and why it works the way it does.
What EchoCast Is
EchoCast is a daily syndication pipeline that takes published posts from six WordPress blogs and distributes them to Medium, Substack, LinkedIn, Dev.to, and Facebook. It runs on a 24-hour embargo so no post younger than one day gets processed. It handles one post per site per run, always choosing the oldest unprocessed post first. The local log file is the source of truth. Nothing is ever auto-published to Facebook; those outputs are saved as drafts for manual review.
The name came from a naming exercise during the design phase, EchoCast for the syndication layer, ReelCast for a planned video pipeline. The cast family. Short, functional, self-explanatory.
The Three-Layer Architecture
The pipeline has three layers with distinct responsibilities. The content layer is WordPress. Every post lives there first, the canonical URL is set there, and everything downstream treats WordPress as the source of record. Nothing gets syndicated that is not already published to WordPress.
The orchestration layer is n8n. It handles scheduling, sitemap fetching, content extraction, Ollama-powered rewrites for each platform format, Dev.to publishing via API, and the trigger calls to the execution layer. n8n is the coordinator and it knows what needs to happen and in what order.
The execution layer is echocast-server, a persistent Express server managed by PM2 that sits alongside n8n on the same machine. It receives POST requests from n8n, triggers the appropriate Playwright script for the target platform, and returns a structured result. n8n treats it as a standard HTTP endpoint.
What n8n Handles vs What Playwright Handles
n8n handles everything that can be done with HTTP and data manipulation: fetching the sitemap, filtering the post queue, extracting content from the live post URL, running Ollama rewrites in four formats as long form for Medium and Dev.to, professional short for LinkedIn, social short for Facebook, newsletter monologue for Substack and publishing to Dev.to via its API. Dev.to is the one platform in the stack that has a working, accessible API. Everything else fell through.
Playwright handles everything that requires a real authenticated browser session. Medium, Substack, LinkedIn company pages, and Facebook, none of these have APIs that work for this use case at the scale and authorization level of a personal publishing operation. Playwright launches Chromium with a persistent auth context per platform and drives the UI the way a human would.
Why Most Platform APIs Fail for Syndication
Medium shut down API token generation. Their publishing endpoints are no longer available to external integrations. LinkedIn’s content publishing API requires approved partner application status not something available to an individual running a personal blog network. Substack has no public API. Facebook’s API exists but is hostile to automation at personal scale.
This is not a niche problem. It is the standard state of social and publishing platform APIs in 2025. The platforms want you to use their web interface. Playwright lets you do exactly that, programmatically. The Medium-specific story, what was tried before Playwright, how deep the session-based approach went before it was abandoned and is documented in full at Why Medium’s API Fails and What We Did Instead.
The Platform Map
The current EchoCast platform map covers six sites across four content tracks. QAJourney and EngineeredAI are the two full-stack sites with Dev.to via n8n API, LinkedIn company pages, Medium, Facebook, and Substack all go through Playwright. HobbyEngineered drops LinkedIn and Dev.to. The three CAS sites are RemoteWorkHaven, MomentumPath, HealthyForge they share a single Medium account and a single Facebook page, which simplified the Playwright auth context management considerably.
The rewrite layer matters here. Ollama handles four format transformations per post using locally running models. The long-form rewrite goes to Medium and Dev.to. The professional short goes to the LinkedIn company page. The social short goes to the Facebook draft. The newsletter monologue structured as problem, reaction, answer, excerpt, call to action then goes to Substack. Each platform gets content shaped for how people read on that platform, not a straight paste of the original post.
What This Enables in Practice
Publishing a post to WordPress and having it distributed across all platforms within the same daily run is the practical outcome. The manual steps are gone. The per-post, per-platform time cost approaches zero once the pipeline is running and stable.
More importantly, the architecture is extensible without structural changes. Adding a new platform means adding a new Playwright script and a new route on echocast-server. The n8n orchestration layer does not need to change. The session management pattern does not change. The build started with the QAJ subworkflow as the template, then cloned and adapted it five times for the remaining sites.
How echocast-server is structured and why the Express approach was chosen over n8n’s Execute Command node is in Triggering Playwright from n8n. How persistent auth contexts are managed across platforms is in Persistent Browser Sessions for Content Automation. The full story of why the HTTP approach to Medium failed is in Why Medium’s API Fails and What We Did Instead.
