Generate Pinterest drafts with n8n and keep a review step

Cover: AI-generated editorial illustration.

Our first useful publishing automation did not need to post anything. It needed to create the drafts, wait until they were ready, and show a clear result for review.

We used n8n to coordinate an existing image-generation service. A verified run returned six generated Pinterest images and their associated article links. All six remained pending; the workflow contained no posting action.

What the workflow actually does#

Manual trigger
  → Start generation
  → Wait
  → Check the job
  → If unfinished, wait and check again
  → If successful, read the draft inventory
  → Show a summary for review

An unsuccessful job follows a separate branch with its exit code and generation log. A request error can still stop execution before that branch; recovery from transport errors needs its own handling.

The output matters as much as the trigger. When a user presses Execute workflow, they should be able to find out what was produced. We finish with a Draft summary that includes the pending count, image links, and the generation log.

The service contract#

The generator was already part of CiteLab’s local publishing setup. It creates images from the site’s content and writes a manifest. n8n coordinates it through three endpoints:

Operation	Endpoint in our service	Purpose
Start	POST /api/run	Request the gen-pins action and receive a job ID
Poll	GET /api/job?id=...	Read completion status, exit code, and log
Review	GET /api/pins	Read draft titles, links, image locations, and posted flags

These endpoints belong to our own application. Installing n8n will not create them. For another site, first define a suitable generator and response format, then adapt the HTTP Request nodes. Keep the service private or appropriately authenticated; do not expose an unrestricted command runner.

Preserve the job identifier#

The initial response contains the job ID. The later status responses do not repeat it. Our first implementation therefore failed when it tried to poll twice using the current item’s missing ID.

Reading the identifier from the start node fixed that single-job workflow. The polling bug walkthrough shows the exact expression and explains why it is not automatically suitable for multiple jobs.

The observed result#

The corrected run reached its summary after two status checks. The inventory reported:

{ "success": true, "total": 6, "pending": 6 }

The generation log confirmed six image files built. Each inventory item reported that its image existed and had not been posted. These checks established generation and inventory reporting in our setup. They did not test public deployment of the image URLs, Pinterest acceptance, click-through rate, or sales.

To inspect your own run, open the execution, select the final summary node, and look at Output. A green workflow does not by itself explain what your reader or operator should do next.

What to review before publishing#

Check that the title matches the article, the text is readable at a small size, the destination page exists, and the image’s claims are supported by the content. Confirm image rights and avoid placing private data in the asset.

Generation and distribution are different capabilities. Pinterest publishing depends on the account, application access, and the applicable API permissions. This workflow does not bypass those requirements, and generating more pins does not demonstrate audience demand.

Start with a useful boundary#

For a small site, a manual trigger and visible review output can be enough to learn whether the process is helpful. Add a schedule or publishing integration only after the underlying content, approvals, failure handling, and platform access are ready.

Use the free readiness checklist to record those decisions. If your next question is where to run n8n, the Cloud versus self-hosting guide sets out the responsibilities without assuming that self-hosting is the cheapest overall choice.