The first version broke on LinkedIn. Everything else fired correctly — Twitter, Instagram via the Graph API, Facebook Page, YouTube Community, Pinterest, TikTok’s content API, and a Telegram channel her client used for their newsletter subscribers — but LinkedIn sat there returning a 422 with a response body that said the content was in an invalid format, which is the kind of error message that tells you exactly nothing useful. The post content was fine. The credentials were valid. The node was configured the way the n8n LinkedIn documentation said to configure it. The actual problem, which took two hours to find, was that the LinkedIn API had quietly updated its schema to require the author field to use a different URN format than what the n8n node was generating, and neither the n8n docs nor the LinkedIn developer changelog had flagged it in a way that would have helped anyone.
The fix was a Code node upstream of the LinkedIn HTTP Request node that reconstructed the payload manually with the correct author URN format pulled from the credential context. It worked immediately after that. It has worked every day since.
I am telling you this upfront because the story that gets written about workflows like this, the eight-platform social publishing pipeline that Amara built for her content agency, tends to skip directly to the part where four people do the work of fourteen. It does not tell you about the LinkedIn URN problem at 11pm or the rate limit wall they hit on TikTok the first week it went live or the IF node logic they had to rewrite three times because the content approval routing was not handling rejected drafts the same way it handled drafts that needed revision. The gap between those two parts of the story is where the actual work lives, and closing that gap is what the workflow actually cost.
Amara reached out to me after I wrote something in the n8n Discord about multi-platform publishing architectures. She had been running a boutique content agency, eight staff at its peak, mostly doing manual work: copywriters drafting, a social media manager reformatting for each platform, someone handling scheduling, someone else managing approvals. The operational bottleneck was not the content. It was the movement of content through the system. A single piece of copy would touch five people before it went live, and by the time it did, half the comment window was gone.
The workflow she ended up with starts with a Webhook node that receives structured content from a Notion database integration her copywriters already used. A Set node normalises the fields into a consistent internal schema regardless of what the Notion payload looks like, because Notion’s API response structure is three levels deep in ways that will frustrate you if you try to map it directly in downstream nodes. An IF node branches on content type, because video content needs different handling than static image posts and carousel posts need different handling again. From there, parallel execution branches handle platform-specific formatting in individual Code nodes before the HTTP Request nodes push to each API.
The approval layer sits in the middle. Before anything goes to the platform APIs, a Webhook response node sends a formatted preview to a Slack channel where the client approves or rejects. Approved posts continue through the workflow. Rejected posts loop back to a notification node that tells the copywriter which platform’s version was rejected and why. This sounds clean when I describe it. Getting it to work required understanding that n8n’s webhook timeout is sixty seconds by default, which is not long enough if a client is slow to respond, and that the solution is not increasing the timeout but restructuring the approval flow as a separate triggered workflow rather than a synchronous wait inside the main pipeline. The documentation for this pattern exists but it is not in the section you find first when you search for it.
Make.com could handle parts of this. The visual clarity of Make’s canvas is genuinely better for showing a non-technical client what the workflow does, and I have used it for simpler publishing flows. But Make’s iteration handling on the multi-platform fanout, where you need each platform to fail independently without stopping the others, requires a level of error handling configuration that becomes genuinely painful at eight branches. In n8n, each branch is an independent execution path and a failure in the Pinterest node does not cascade to the TikTok node. That independence is structural, not something you configure around.
Amara’s agency now runs with four people. The workflow handles the distribution layer completely. The humans handle relationships, strategy, and creative decisions that the workflow cannot make. She told me the hardest part of the transition was not building the automation. It was convincing two staff members who saw it coming that this was a change in what the agency could offer, not a replacement of what they did. One of them now manages the workflow itself and has extended it twice to add new platforms.
The agencies that will struggle in the next five years are not the ones that cannot afford automation tools. They are the ones that cannot separate the work humans need to do from the work that a well-built workflow can do instead, and have not made peace with that distinction yet.
Olaitan Oladipo holds a BSc in Sociology from Olabisi Onabanjo University. He is a self-taught automation builder who has spent years inside n8n doing the work that most tutorials skip: debugging OAuth errors at 2am, migrating client automations from Make.com mid-project, fighting reverse proxy misconfigurations on AWS EC2, and figuring out through trial and error what actually holds up in production versus what only looks clean in a demo.
He is not a developer by training and not a SaaS founder. He is the person in the Discord server who actually answers the question instead of linking to the docs.
His writing on n8n Automation Tutorial covers self-hosting, AI agent workflows, tool comparisons, and the security vulnerabilities the automation industry would rather not discuss. He has built AI-assisted invoice approval flows using OpenAI function calling, connected Claude via HTTP Request nodes, and holds considered opinions about Zapier, Make.com, LangChain, and CrewAI that their marketing teams would not appreciate.
He writes for people who are technical enough to follow a tutorial but experienced enough to want the honest version.