Pinterest Autopilot V4: What I Fixed, What I Broke, and the API Key I Had to Rotate

Pinterest Autopilot started as a simple pin-generation loop in V3 and turned into something closer to a real system by V4, multi-board posting, a dual-schedule setup running both in the cloud and on a local machine, and a packaged product with a full guide. It also gave me one of the more uncomfortable moments I've had building any of these tools, which felt more worth writing about than the feature list.

The moment I found a live key sitting in a file I'd already shared

While working through V4, I opened the shared workflow file and found hardcoded, live API keys for both Gemini and Groq sitting in plain text inside it, not in a `.env` file, not in a credentials store, just pasted directly into the JSON. This is the kind of mistake that's easy to make when you're moving fast between local testing and building the "shareable" version of a workflow, and easy to miss because the workflow still runs fine either way.

I rotated both keys immediately, generated new ones, updated every place that referenced them, and revoked the old ones so anything that had seen that file couldn't use them. Nothing came of it that I know of, but that's the point: you don't usually find out a key leaked until it's already been used against you. The fix that actually matters isn't "don't make the mistake." It's building the workflow so the mistake can't happen quietly. That's what became the Config node.

What V4 actually added over V3

Multi-board posting

V3 only posted to a single board at a time. Fine for testing, not fine for a real content calendar. V4 added board_index modulo-2 cycling, splitting posts evenly across boards instead of dumping everything into one, which is closer to how an actual account should behave.

A Performance tab

Every pin now logs its result to a dedicated Performance tab in the Google Sheet, instead of just trusting that a run "probably worked," there's a record of what actually posted, which made debugging every other issue on this list faster.

One Config node instead of scattered credentials

This is the node that grew directly out of the key-leak scare. Every credential and URL now lives in a single node instead of being scattered across whichever node happened to need it: Groq, Cloudflare, the render server, ImgBB, the Make.com webhook, the Sheet ID, the Slack webhook. If this workflow ever gets shared again, there's exactly one place to check, and exactly one place to swap in new keys.

Two schedules sharing one State tab

V4 split into a Railway instance running overnight and a local NSSM-managed instance running during the day, both reading and writing the same State tab, on schedules designed not to overlap. Getting this right meant making sure neither instance would grab a pin the other had already claimed, which is a smaller version of the idempotency problem I'd eventually solve properly in V5.

Packaged as an actual product

Workflow JSON, a PDF setup guide, a product spreadsheet template, and a README, the same packaging pattern as everything else I ship, so a buyer isn't left guessing how to wire it up themselves.

Bugs inherited from V3, fixed here

Two problems followed V4 over from V3 and got fixed properly this round:

• Replaced Gemini with Groq (Llama 3.3-70b) for generation, more stable output for this use case.
• Fixed a state-freeze bug where Groq would occasionally return malformed JSON and the whole workflow would just stop. Fixed with a try/catch plus a regex fallback to pull usable content out of a broken response instead of failing silently.

New bugs V4 introduced, and fixed

• Pinterest description overflow. Descriptions over 800 characters were getting silently truncated by Pinterest's own API, no error, no warning, just a shortened pin that looked fine until you noticed it cut off mid-sentence. That's the kind of bug that only surfaces once a real post looks broken in public.
• Pinterest API error 2787, intermittent, server-side flakiness on Pinterest's end. Resolved with retry logic instead of trying to "fix" something that wasn't actually broken on my side.
• A Groq model swap bug that started throwing errors after switching models mid-build.
• A repeated-bullet rendering bug in pin generation, eventually traced back to a fallback path in the Code node that was quietly re-triggering instead of failing cleanly.

What I knew about and left broken

One issue made it into production on purpose, unfixed: if image generation or the Puppeteer render server failed, the workflow would silently fall back to a stored emergency image and post it anyway, no alert, no log entry calling it out. I knew about this in V4 and shipped anyway, because the alternative was blocking every post on a render server that mostly worked. That silent-fallback problem didn't get fixed until V5, alongside a proper idempotency system. That's a separate post.

I've gotten real, specific feedback from the n8n community on things like idempotency and generation/delivery separation since shipping this, feedback that shaped V5 directly. If you're running a similar posting pipeline and have hit the same class of problems, I'd genuinely like to compare notes.