Social Distribution Network
Five platform pipelines turning one published post into native posts, stories and reels — each with its own publish protocol, and its own case study.
- Client
- EpsolDev
- Category
- Automation Engineering
- Completed
- 2026-08-15
- Built with
- n8n, Google Vertex AI, REST API
- Topics
- API Development, Automation
n8n 5 platforms 262 nodes Publishing daily
One published blog post becomes a native post on five platforms — caption, image, video, story, all generated, all verified. This is the overview; each pipeline has its own case study, because each platform's publish protocol is genuinely different.
Driven by the Blog Automation Engine, on top of Custom Blog Management.
The five
| Pipeline | Nodes | What makes it different |
|---|---|---|
| 70 | three surfaces per run — feed, story, reel — and two nested async polling loops | |
| 61 | photo posts in one call; reels need a three-phase resumable upload | |
| YouTube | 47 | no image stage at all — the video is the post, behind an OAuth exchange |
| 44 | takes bytes directly, so no media round-trip and nothing to clean up | |
| Google Business Profile | 40 | local SEO surface rather than social; OAuth token minted per run |
What they share
Every pipeline opens identically, and for the same reason the blog engine does — one graph serves every client site:
Schedule ─┐
├─> Config ─> Dispatch ─┬─> one site (webhook)
Webhook ─┘ └─> sites_list (scheduled)
│
Loop Over Sites
│
Get Config ─> Due? ─> Claim ─> generate ─> publish ─> Record Post- Per-site scheduling. A site posting three times a week and one posting daily share one workflow and one trigger.
- A claim gate. A scheduled tick and a manual run cannot double-post the same site.
- Primary-and-fallback generation, with a wait between attempts — the usual first-attempt failure is a transient rate limit, and an immediate retry reproduces it.
- Credentials from the control plane, fetched per run. Rotating a client's token needs no automation change.
- One
CBM Record Postthat every terminal branch reaches, success or miss.
Why not one workflow with a switch
The sites are the same across all five. The platforms are not.
Instagram will not accept a post — it accepts a container, processes it asynchronously, then publishes it, and it may still fail. Facebook publishes a photo in a single call but needs a three-phase upload session for a reel. YouTube wants an access token minted per run and the video bytes before the metadata. LinkedIn wants an author URN resolved live, and takes the image bytes directly. Google Business Profile wants a post bound to a location.
Forcing those into one graph means a switch node wrapping every step — five graphs pretending to be one, with a shared blast radius. Splitting them means a change to the reel protocol cannot break the photo path, and a platform outage is one workflow red on the dashboard instead of one branch in a graph nobody can read.
Media hygiene
Three of the five need a publicly fetchable URL rather than bytes, so the generated image is uploaded to the content platform's media library only to obtain one — and deleted once the platform has ingested it.
| Pipeline | Media round-trip |
|---|---|
| Instagram, Facebook, Google Business | upload for a URL, delete after publish |
| none — binary straight to the asset API | |
| YouTube | none — bytes straight to the resumable upload |
The library never fills up with thousands of one-use social images. Each delete sits after publish verification, so a failed post keeps its asset for inspection.
Lineage
The archive on the same instance holds a dozen superseded per-account social workflows — one per platform, per account. Adding a client meant duplicating a graph; improving a prompt meant editing every copy.
These five replaced all of them by making the site a parameter instead of a copy.
Stack
n8n Instagram Graph API Facebook Graph API YouTube Data API LinkedIn API Google Business Profile API Google Vertex AI Imagen Veo OAuth 2.0 JavaScript