Am I an idiot? - Storing Images Generated by ChatGPT to Softr DB

Ask the community
1

Hi all,

If you are reading this, I apologise for the Clickbait title.

I’m trying to generate images with ChatGPT via an API call from Softr then store this image in my base.

I want to do this completely internal to Softr Workflows because everything is so clean and clear inside the Softr ecosystem. I’m I want to avoid Webhook calls to Make and then return API calls to Softr from Make. I’m happy to play around with scripts.

So here it is:

  1. I’ve sent an API call to ChatGPT to generate an image. (Successful)
  2. A successful image generation has been returned as a base64 reply in JSON. (Successful)
  3. I want to store this as an image in my Softr base using only Workflows. (Still trying)

Every other time I have used Workflows, I am shocked by how ridiculously easy and workable it is. So I am assuming that I am just an idiot here.

Does anyone have a solution that does not involve my current workaround which is as follows: Softr>Webhook>Make>Google Drive>Softr API call?

This process just seems so inelegant, so “not Softr.”

Any help would be greatly appreciated. Especially if you tell me I’m an idiot and show me the light.

Thanks in advance,

Steven

2

Hey @StevenQ You’re not an idiot, you’re just hitting one of the current limitations of Softr Workflows.

Right now, Workflows can send API requests and receive the base64 response, but they don’t natively convert a base64 string into a file and upload it to a File/Image field in your Softr data source. File fields expect a publicly accessible file URL (or a direct upload via supported integrations), not raw base64.

So if ChatGPT is returning something like:

data:image/png;base64,iVBORw0KGgo...

Workflows can store that string in a text field, but they can’t decode it and save it as an actual image file inside your base.

If you want to stay as close to “pure Softr” as possible, you have two workable options:

One option is to modify your OpenAI image generation call to return a hosted URL instead of base64. Some image endpoints support returning a URL instead of b64_json. If you receive a temporary image URL, you can store that directly in an Image field and avoid Make entirely. The tradeoff is that those URLs can expire, so it’s not always reliable long-term unless you re-host the file.

The more robust option (and the reason your current workaround works) is to use an external step that converts base64 to a file and hosts it somewhere accessible, then pass the public file URL back to Softr via API or Workflow. That’s not inelegant it’s just filling a gap in file handling.

At the moment, there isn’t a fully internal “decode base64 → create file → attach to record” action inside Softr Workflows.

If Softr introduces base64-to-file handling in Workflows, this becomes trivial. Until then, you either request a hosted URL from the image API or keep one lightweight external step purely for file conversion and storage.

You’re thinking about it the right way. It’s just a platform boundary, not a you problem.

3

Thanks Hassaan for your very prompt and detailed reply. I’ll follow your advice!

1 Like