LinkedIn Publishing Pipeline

The only pipeline that never touches the media library — LinkedIn takes bytes directly, so identity is resolved live and the image is registered, uploaded and posted with nothing to clean up.

Client
EpsolDev
Category
Automation Engineering
Completed
2026-08-15
Built with
n8n, Google Vertex AI, REST API
Topics
API Development, Automation
LinkedIn Publishing Pipeline

n8n 44 nodes Direct binary upload Publishing daily

The only pipeline in the set that never touches the content platform's media library. LinkedIn accepts image bytes directly, so the generated image goes straight from the generator to LinkedIn's asset API — no upload, no public URL, no cleanup.

The whole LinkedIn workflow: generation on the left, identity resolution and the asset upload chain on the right

Part of the Social Distribution Network.

Same opening, different exit

Dispatch, the site loop, the schedule gate and the claim gate

Dispatch, Loop Over Sites, the per-site due check, the claim gate, CBM Next Post → CBM Get Identity → CBM Get Prompts, then caption and image generation with primary-and-fallback on both.

Then the divergence, visible in a single connection:

Prep Image ─> LI Get Creds          (LinkedIn: bytes go direct)
Prep Image ─> CBM Media Upload      (Instagram, Facebook, GBP: needs a URL)

That one edge removes three nodes and an entire cleanup concern from this graph.

You cannot post as a token

Caption and image generation with their fallback branches

LinkedIn will not accept "post this, here is my token". It needs an author URN — the identifier of the member or organisation the post belongs to. So the workflow resolves identity before it does anything else:

LI Get Creds -> LI Parse Creds -> LI Creds OK? -> LI Get Me -> LI Me OK?
                                                                   │
                                                            LI Image Init

LI Get Me is a live call, not a cached value. A token that is valid but no longer associated with the expected page fails here, at zero cost, rather than posting to the wrong account.

Registering an asset, then waiting for it

Identity resolution and the four-step asset upload with its readiness check

LinkedIn's image flow is a register-then-upload handshake:

  • LI Image Init — register the intent, receive an upload URL and an asset URN
  • LI Image Bin — prepare the binary payload
  • LI Image Upload — send the bytes
  • LI Image Wait → LI Image Status → LI Image Ready? — the asset is processed asynchronously

Only then does LI Create Post reference the asset URN, and LI Verify confirms it.

The one deliberately unbounded-looking branch

LI Image Ready? false does not loop back. It goes to LI Image Wait 2 and then straight to LI Create Post:

LI Image Ready? ─┬─ yes ──────────────> LI Create Post
                 └─ no ─> LI Image Wait 2 ─> LI Create Post

That looks like a missing retry loop. It is a choice. One extra wait, then post anyway. LinkedIn's asset processing is fast and usually already finished; the status check is a courtesy, not a gate. Blocking the post on a slow status read would trade a near-certain success for an indefinite wait.

The other pipelines poll with a give-up because they wait on video, which genuinely takes minutes. This waits on a still image, which does not.

Nothing to clean up

No CBM Media Upload, so no CBM Media Delete. The graph ends LI Verify → CBM Record Post → back to the site loop. Fewer moving parts than any other image pipeline in the set, because the platform asked for less.

Stack

n8n LinkedIn API Google Vertex AI Imagen JavaScript REST API

All projects