For image-based GBP posts, the uploaded image is required and must actually be read before any content is generated.
Current setup:
- Lovable sends
image_base64- n8n maps
image_base64andimage_mime_type- The image branch is supposed to run:
Has Image Data → Extract Image Facts → Merge Image Facts → GBP Content Strategist → GBP Post WriterWhat I need:
- If
image_base64is present, the workflow must successfully extract usable facts from the image before continuing.- The generated post must use those image-derived facts.
- Do not fall back to text-only generation if image extraction fails.
- If the image cannot be read or no usable facts are extracted, stop the image branch and return a clear
NEEDS_DAVEor error message explaining that the image could not be processed.- Keep the existing V1 text-only flow unchanged.
- Do not change Airtable, Humanizer, Final QA, callback logic, response logic, or publishing behavior.
Please inspect the current image branch first, identify the exact reason the image is not being read correctly, and then make only the minimum change required.
Afterward, tell me:
- What exact node was wrong
- What exact change you made
- How the image is now being passed into
Extract Image Facts- What happens if image extraction fails
Hey @David_Sichel, while you wait for a response, here are some things that might help:
Suggested resources
Automatically matched to your question.
Docs:
Forum:
@Carolyn, @jabbson, @mohamed3nan - you’ve helped with similar issues before, can you take a look?
Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here.
Thanks and sorry to be such a pain I get 95% done of all my project and get stuck lol
Hey @David_Sichel,no problem at all, We’re here to help. So in this case a base64 string sitting in JSON isn’t binary, and the vision node can only read binary, so the image branch never actually had an image to look at. Someone hit this exact thing before and it turned out to be the same cause.
Put a Convert to File node directly in front of Extract Image Facts, operation Move Base64 String to File, Base64 Input Field image_base64, and set the MIME Type option to {{ $json.image_mime_type }} since you’re already carrying it. Leave that node’s On Error on Stop Workflow and a malformed image stops the branch there instead of quietly falling through to your text-only path.
Linking to your previous question:
Thanks again for the earlier answer — it correctly identified that the base64 image needed to be converted to a binary file before the vision step.
We made that change, but the workflow is still failing because the old Download Image node is still executing and returning:
Bad request - please check your parameters
InvalidJWT
The intended active image path is now:
Map Generate Input → Has Image Data → Convert to File → Extract Image Facts → Merge Image Facts → GBP Content Strategist
The old Supabase signed-URL path should no longer be active.
Could you help me confirm why Download Image is still executing?
Specifically:
- Is there still an active connection into
Download Imagesomewhere? - Could another branch or stale connection still be triggering it?
- Should
Download Imagebe completely disconnected or deleted now that the workflow uses base64? - Is there anything in n8n that can cause a disconnected old node to still appear in an execution?
The current goal is simply to make sure the workflow uses only the base64 → binary path and never executes the expired Supabase signed-URL path.