Facebook Publishing Pipeline

One platform, two upload protocols — a photo posts in a single call while a reel needs a three-phase resumable session, ordered so a reel failure never costs the post.

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

n8n 61 nodes Two protocols, one platform Publishing daily

Facebook is the clearest illustration of why these five pipelines could not be collapsed into one: the same platform uses two completely different upload protocols depending on whether you are posting a photo or a reel.

The whole Facebook workflow: the short photo path above, the long reel upload chain below

Part of the Social Distribution Network.

The photo path is one call

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

After the shared front half — dispatch, site loop, FB Due?, claim gate — the photo path is the simplest publish in the entire set:

Prep Image -> CBM Media Upload -> Parse Media -> CBM Get FB Creds
                                                       │
                                              Creds OK? -> FB Publish Photo
                                                                  │
                                                          Verify Publish -> Published?

One request. No container to create, no status to poll, no promotion step. Compare that with Instagram, where the same outcome needs create-container, wait, publish and verify.

The image still round-trips through the content platform's media library, because the Graph API wants a fetchable URL rather than bytes — and CBM Media Delete removes it the moment the post is confirmed.

The reel path is a three-phase upload session

Caption and image generation with fallbacks, and the reel generation branch

Reels do not go through the photo endpoint at all. They use a resumable upload session, which is three ordered calls that must all succeed:

FB Reel Start   ->  open a session, get an upload target
FB Reel Upload  ->  send the video bytes
FB Reel Finish  ->  close the session and publish
                        │
                  FB Reel Verify -> Reel Media Delete

Credentials, photo publish, and the three-phase reel upload with its verification

Before any of that, the video has to exist — which is its own asynchronous wait:

Reel Veo Submit Primary → Reel Have Op 1? → (fallback submit) → Reel Prep Op → Reel Wait Poll → Reel Veo Poll → Reel Poll Gate → Reel Video Ready?, with Reel Give Up? as the escape hatch.

Two protocols means two failure vocabularies A photo either posts or it does not. A reel can fail at generation, at session start, mid-bytes, or at finish — and each of those needs its own exit that still reaches CBM Record Post. Folding both into one generic "publish" step would have meant a switch node wrapping every stage.

Ordering: photo first, reel second

CBM Media Delete → FB Reel Enabled? — the reel branch only starts after the photo has published and its asset has been cleaned up.

That ordering is deliberate. The photo is the cheap, reliable output; the reel is the expensive, flaky one. Doing them in that order means a reel failure never costs you the post you were always going to get. The reliable output is never held hostage by the optional one.

Everything else is shared

Per-site scheduling through FB Due?, the claim gate against double-posting, primary-and-fallback generation on both caption and image, credentials fetched per run from the control plane, and a single CBM Record Post that every terminal branch reaches — success or miss.

Stack

n8n Facebook Graph API Google Vertex AI Imagen Veo JavaScript REST API

All projects