Discover it.Let an editor decide.Preserve every failure.

Start with one source, one WordPress draft, a named editor, and synthetic records. Sending an inquiry creates no contract or charge.

Conclusion: keep discovery, editorial approval, and publishing separate, then retain each channel's result so a retry cannot repost a successful item. For teams planning a content workflow, this page shows the tested states, failure boundaries, and evidence you need to verify before production.

For: teams that need human approval before publishing and must retry one failed channel without reposting successful channels.

You will see: the tested states for discovery, deduplication, approval, draft creation, publishing, and partial failure.

Prepare before a real pilot: one source, one destination, a named editor, an approval rule, representative test records, and the destination's API requirements.

Next: inspect the measured cases, then limit the first real test to one source and one destination with publishing disabled.

What this example proves: this is a public technical example, not a client deployment. It uses fictional records and a local state fixture only. No real media data, personal information, credentials, external APIs, or social accounts are connected.

One editorial state becomes the contract between stages

Discovery, editorial work, creation, and publishing remain separate instead of becoming one unmanageable canvas. Every stage carries the same content_id and explicit state. If execution stops, the record still shows what was approved and which destination failed.

01IntakeDISCOVERED
02NormalizeNORMALIZED
03Human approvalAPPROVED
04Draft readyREADY
05ReconciledPUBLISHED
Five-stage editorial content workflow from intake and normalization through human approval, draft creation, and reconciled destination, with blocked and isolated retry paths
Illustrative state map: approval blocks unapproved publishing; a partial failure retries only the failed destination.
  1. Discovery: poll RSS feeds, catalog APIs, and permitted web sources on a schedule.
  2. Normalize: map source-specific fields into type, artist, title, date, source URL, and external IDs.
  3. Deduplicate: compare external IDs, canonical URLs, and content fingerprints in layers.
  4. Editorial approval: a human accepts, corrects, or rejects each item. Unapproved records cannot reach creation or publishing.
  5. Creation and review: create editable copy and asset references grounded only in approved source records.
  6. Publish and reconcile: store each destination's result, post ID, URL, timestamp, and error independently.

Measure how it fails—not just how often it succeeds

Synthetic records were sent through n8n 2.33.7 to test the happy path, duplicate intake, missing approval, partial delivery, safe retry, and invalid input. Channel calls were recorded by a local state fixture on the same isolated network; no external publishing API was contacted.

Approval gateBLOCKzero unapproved publishes
Duplicate+0existing content returned
Partial failureISOLATEDsuccessful channel not reposted
EvidenceJSONinput, state, outcome
CaseInvariantMeasured result
Happy pathOnly approved content reaches creationAll stages complete / per-channel status retained
DuplicateDo not register the same candidate twiceExisting content_id returned / stored count unchanged
UnapprovedDo not call a publishing endpointblocked / zero publish attempts
Partial failureDo not repost successful destinationsOnly the failed destination retried
Invalid inputReject records without a usable source contractrejected / zero downstream attempts

API constraints to prove before production

Discovery and publishing are not solved by connecting nodes. Account types, app review, OAuth scopes, media formats, platform rules, and rate limits must be proven with the production owner accounts early.

  • Spotify: GET /browse/new-releases was removed in February 2026. Artist-specific release discovery needs a new design using available catalog search, permitted alternative sources, and RSS rather than relying on that endpoint.
  • Instagram: no private-login automation or anti-bot bypass. A small proof must establish what the API can reliably read from eligible professional accounts.
  • TikTok: Direct Post requires a registered app, approval for video.publish, and user authorization. Posts from unaudited clients remain private.
  • WordPress: use the REST API with a revocable Application Password; never put the owner's primary password in a workflow.

Recommended first milestone: take one discovery source through normalization, editorial queue, approval, and WordPress draft creation. Add direct social publishing destination by destination after its app ownership and approval path is confirmed.

Workflow and execution evidence

What this example cannot prove

  • Client delivery, production SLA, or long-term reliability
  • Live Spotify, Apple Music, Instagram, TikTok, YouTube, or WordPress account integration
  • Editorial quality of generated copy or brand fit of image and video templates
  • Approval of an application or publishing scope by any platform
  • Production editor authentication or approval identity—the probe supplies a synthetic approval assertion

Primary sources

PAID DISCOVERY

Prove one vertical slice
before pricing every stage.

One source, an editorial queue, deduplication, human approval, and a WordPress draft in a fixed first milestone. Prove API permissions and operating load with representative data before expanding.

Discuss a scoped pilot

Measured: n8n 2.33.7 / synthetic data / no external network / no customer data / 2026-08-13 JST