Automate Midjourney with Make.com: What’s the Exact Blueprint?

I’m gonna show you exactly how I use Midjourney within Make.com to make images while I’m sleeping. 🤙 And this is proof, not some theoretical “you could do this” situation. This is a real workflow I built, tested, broke, fixed, and now run on autopilot.

If you’ve been manually generating Midjourney images one by one, saving them to your desktop, and renaming them something like “final_final_v3_REAL.png”, then honestly we need to talk. 😤

The whole thing runs on two Make.com scenarios, a Midjourney API bridge called ImagineAPI.dev, and a clever little ChatGPT Vision trick that automatically names your images based on what’s actually in them. And I’m giving you the full blueprint, completely for free.

If you’re already building automations with Make.com, this is going to slot right into your existing setup.

Why You Need Two Scenarios (Not One)

This is the thing that trips people up first. You can’t just build one long Make.com scenario for this. It has to be split into two.

Why? Because Midjourney doesn’t generate images instantly. When you send a prompt, it goes through that whole percentage-loading thing you know from Discord, 25%, 30%, 40%, all the way to 100%. Your first scenario fires off the prompt and then it’s done; it’s not sitting around waiting.

The second scenario listens for a webhook that fires only when the image is actually complete.

This is broken up into two scenarios, and it has to be broken up into two scenarios for this to work. One triggers. One catches. That’s the architecture, and I can’t stress that enough.

The first scenario is set to run on demand (because I’m just showing the Midjourney piece here; in production you’d have upstream modules generating dynamic prompts). The second scenario must be set to immediately so it catches that webhook the moment the image finishes generating.

This has to be immediate and the first one has to be on demand. Get that backwards and nothing works.

What You Actually Need (And What It Costs)

Before we get into the build, here’s your shopping list:

So you’re looking at roughly $27–$47/month depending on your chosen plans to run this entire system. I have the $30 Midjourney plan because I use this quite a bit, but the $10 Basic plan works fine to get started.

Check ImagineAPI.dev’s current pricing for the latest rates, as plans may have changed.

Why ImagineAPI.dev and Not UserAPI.ai

I have opinions here, and I’m not gonna sugarcoat them.

A lot of tutorials out there point you toward UserAPI.ai for connecting Midjourney to Make.com. And look, I tried it. I genuinely did. There are a lot of videos showing you how to use it, but the problem is that once I got to the pricing, it tells me how much I have to pay, but then it needs me to pay with crypto or something like that.

And I was just like… no.

I’m not trying to join a new payment processor to buy crypto so that I could use it for this platform. I’m just not trying to do that. That really turned me off from using UserAPI.ai, so I didn’t go with them.

ImagineAPI.dev is straightforward. Credit card, monthly plan, done. They also have a native Make.com module, which is super handy. You’re not messing around with raw HTTP requests and custom headers.

You just drop in the module, add your API key, and you’re rolling. I’ve gone back and forth with the developer on support issues and it’s been genuinely great.

Worth knowing: there’s no official Midjourney API. Midjourney has never released a fully public, generally available API. Every “Midjourney API” you see is an unofficial third-party service that’s figured out how to interface with Midjourney’s backend.

ImagineAPI.dev is upfront about this, calling itself “The (unofficial) Midjourney API.”

Building Scenario 1: The Trigger

This is the simple one. You’re setting up a scenario that sends a prompt to Midjourney via ImagineAPI.dev.

Step 1: Add the ImagineAPI module to your scenario. Search for it in Make.com’s module library. It’s called “Generate an Image.” Click it, add it to your scenario, done.

Step 2: Create a connection. Go to your ImagineAPI.dev dashboard, find your API keys section, copy your key, and paste it into the connection setup in Make.com. That’s quite literally it for authentication.

Step 3: Add your prompt. In my demo I just typed something like “image of a dog with wings” as plain text. But in a real production workflow, you’d have upstream modules—maybe a ChatGPT module generating prompts, or a Google Sheets row feeding in data—piping a dynamic variable into this field.

You’re using Make.com, so you want dynamic variables. You don’t want to come here and manually type this out every time.

Here’s a little trick I do: I always have some pre-loaded style modifiers appended to my prompts. Things like “HD detail, duotone illustration, comic book style” and specific colors that I really want to emphasize.

You can also add your regular Midjourney parameters (like --ar 16:9 or --v 6.1) directly in the prompt field. They work exactly the same as they would in Discord.

Once you hit run, this scenario fires the prompt off to ImagineAPI, which sends it to Midjourney, and… that’s it. Scenario 1 is done. It just sent data and moved on with its life. It looks like nothing happened, right? It just ran. But what it actually did is launch the generation on Midjourney’s side.

Building Scenario 2: The Webhook Catcher

This is where the real magic happens, and it’s got more moving parts.

Setting Up the Webhook

First, you need a custom webhook in Make.com. Create a new scenario, add a Webhook module (custom webhook), click save, and it’ll generate a URL. Copy that URL.

Now go to your ImagineAPI.dev backend, navigate to Webhooks, click “Add a Webhook,” and paste that Make.com URL in there. What this does is tell ImagineAPI: “When an image is done, send the data here.”

Getting the Image Data

Once the webhook confirms the image is complete, the next module grabs the image data using the ID from the payload. Midjourney generates four image variations per prompt (the classic 2×2 grid), so you’re getting four separate upscaled URLs back.

To process all four, you need an iterator module. The iterator takes the array of upscaled URLs and splits them into individual bundles, one per image. And here’s a specific thing that caught me up: when you’re configuring the iterator, select the plain upscaled URLs array, not the nested version.

Get it wrong and the whole thing chokes.

The HTTP Get

After the iterator, an HTTP “Get a File” module downloads each image using the URL value from the iterator. This pulls the actual image file into Make.com’s memory so you can do stuff with it. The variable here is URL, and the URL is the value of the iterator. Straightforward.

The ChatGPT Vision Trick (This Is the Cool Part)

This part is totally optional, but it’s my favorite piece of the whole build.

After downloading each image, I pass it to OpenAI’s “Analyze Image with Vision” module. The prompt is dead simple: “What is this image?” ChatGPT Vision looks at the image and comes back with something like: “The image appears to be an aesthetic representation of a dog with wings, possibly styled in a pop art format.”

Each of the four images gets its own unique description because they’re all different images. The Vision model is actually looking at what’s in each one, not just regurgitating your original prompt.

Then I pass that description to a second OpenAI module, this time just a regular GPT-4o-mini completion, with a prompt like: “Based on that description, create a sanitized file name that’s less than 100 characters.”

I use GPT-4o-mini here because from what I saw it’s the cheapest model. I can run this for a month and pay less than a dollar.

Saving to Google Drive

The last module takes each image file and uploads it to a specified Google Drive folder, using the ChatGPT-generated filename as the actual file name.

So instead of downloading four images named image_001.png through image_004.png, I end up with files like “dog-with-wings-pop-art-style.png” and “winged-dog-duotone-illustration.png” sitting in my Drive—organized and descriptively named—without me touching a thing. It’s great.

The Operations Math

One thing people worry about with Make.com is operations. The free tier gives you 1,000 per month, and people panic about burning through them.

Here’s how this workflow breaks down per run: you’ve got the trigger (1 operation), the webhook catch (1), getting image data (1), the iterator processing four images (4), four HTTP gets (4), four Vision analyses (4), four filename generations (4), and four Google Drive uploads (4). That’s roughly 23 operations per run.

At 1,000 free operations, you can run this about 43 times per month before you’d need to upgrade. That’s around 172 images. For most people doing content creation, that’s more than enough to stay on the free tier.

The whole point of this build is getting Midjourney out of the “manually click around in Discord” phase and into something that works for you in the background. Two scenarios, one API bridge, and a ChatGPT trick for filenames. That’s the entire system.

It’s not complicated once you see it laid out, and honestly the hardest part was finding an API provider that didn’t make me want to pull my hair out (sorry, UserAPI.ai).

If you’re a content creator, marketer, or solo entrepreneur who needs consistent image output without babysitting Discord all day, this is the workflow. Set up the two scenarios, connect your ImagineAPI account, add the Vision module for those auto-generated filenames, and point it all at a Google Drive folder.

Then go do literally anything else. The images will be there when you get back.