How to aggregate multiple HTTP downloads (images) into ONE Gemini request in Make?

Questions
, ,
1

:bullseye: What is your goal?

Hi everyone,

I’m using Make with this flow:

Glide Get Rows → Iterator (rows) → Iterator (images) → HTTP (Download a file) → Array Aggregator → Google Vertex AI (Gemini)

Each row can contain multiple images (array).

Expected behavior:
HTTP runs once per image (this is fine)
Array Aggregator groups all images of the same row
Gemini should run once per row, receiving all images in one request

Actual behavior:
HTTP runs N times (expected)
Array Aggregator also shows N operations (the group by rowId didn’t work)
Gemini sometimes still runs N times instead of grouping by row

The main scenrio is every row is a user submitted request and can contain multiple images, and I want to evaluate them once per row !

:thinking: What is the problem & what have you tried?

My question:
What is the correct way to configure the Array Aggregator “Group by” so that all image bundles for the same row are combined into ONE output bundle (and Gemini runs only once)?

Specifically:

Should “Group by” use the row-level $rowID?
(but it didnt work cause the array aggregator only works on the bundle not the operation level)
Thanks! Any clarification on bundle vs operation behavior would be very helpful.

:camera_with_flash: Screenshots (scenario flow, module settings, errors)

Screenshot 2026-01-06 at 13.34.35.png
Screenshot 2026-01-06 at 13.34.35.png2364×514 74.3 KB

2

or any workarounds that canr produce the same results are all welcomed

3

This is a classic bundle-boundary issue in Make, not a Vertex or HTTP problem.

Key point:
Array Aggregator groups bundles, not operations, and in your flow the row context is already lost by the second Iterator.

Because you iterate rows → then iterate images, each image becomes its own bundle, and the aggregator no longer has a stable “row-level” boundary to collapse back into one bundle. That’s why rowId grouping feels like it “should work” but doesn’t.

At a high level, the fix is:

  • Make sure the row-level bundle survives until aggregation, or

  • Move aggregation so it runs before the row context is flattened, then iterate images only inside that scope.

Once the row boundary is preserved, Gemini will naturally run once per row.

If you want, DM me and I can explain the clean pattern for “one request per row with multiple images” step by step (iterator placement + aggregator setup).

1 Like
5

Hi @bill255203 and @Kota435,

I encourage you to keep this conversation open and accessible by posting messages in this topic. That way, every Community Member can benefit from it.

2 Likes
6

Hi Henk, I am really willing to solve the problem together and post messages in this topic, please unban my account and the post asap, really appreciated !!

7

That makes sense, and I agree that sharing knowledge publicly is valuable.

I’m happy to keep discussing the general approach and reasoning here so others can learn from it.
For more detailed, scenario-specific fixes (exact node placement, mappings, or restructuring), it’s usually easier to handle those one-on-one, since they depend heavily on the full context.

I’ll continue contributing at a high level here :+1:

2 Likes
8

Hi Kota this is my original question can you give me some more instructions about how to resolve this issue,

I’m using Make with this flow:

Glide Get Rows → Iterator (rows) → Iterator (images) → HTTP (Download a file) → Array Aggregator → Google Vertex AI (Gemini)

Each row can contain multiple images (array).

Expected behavior:
HTTP runs once per image (this is fine)
Array Aggregator groups all images of the same row
Gemini should run once per row, receiving all images in one request

Actual behavior:
HTTP runs N times (expected)
Array Aggregator also shows N operations (the group by rowId didn’t work)
Gemini sometimes still runs N times instead of grouping by row

The main scenrio is every row is a user submitted request and can contain multiple images, and I want to evaluate them once per row !

:thinking: What is the problem & what have you tried?

My question:
What is the correct way to configure the Array Aggregator “Group by” so that all image bundles for the same row are combined into ONE output bundle (and Gemini runs only once)?

Specifically:

Should “Group by” use the row-level $rowID?
(but it didnt work cause the array aggregator only works on the bundle not the operation level)
Thanks! Any clarification on bundle vs operation behavior would be very helpful.

9

You’re very close — this is mainly a bundle context problem caused by the 2nd Iterator.

Why “Group by rowId” didn’t work

When you do:

Iterator (rows) → Iterator (images)

the images iterator outputs bundles that often contain only the image item, and the original row fields (like rowId) may be missing or empty in those bundles. If rowId is not present (or not consistent), the Array Aggregator can’t group correctly, so Gemini ends up running N times.

Also: seeing N operations on the Array Aggregator is normal. The key is whether it produces 1 output bundle per row.

The clean fix (recommended pattern)

Step 1) Preserve rowId into every image bundle

Before the images Iterator, transform your images array into an array of objects that includes both:

  • rowId (from the current row)

  • image (the image item)

So the images Iterator iterates objects like:
{ rowId: "123", image: <one image> }

How you do this depends on your exact Glide output shape, but the goal is: each image bundle must carry rowId.

Step 2) Configure the HTTP module

In HTTP (Download a file):

  • Download using the image field from the image-bundle

  • Keep rowId available in the bundle (it should be if Step 1 is done)

Step 3) Configure Array Aggregator correctly

Set the Array Aggregator to:

  • Source module: the HTTP Download module

  • Group by: the preserved rowId (from the image bundles)

  • Aggregated fields: the downloaded file/binary (or whatever Gemini expects)

Now the Aggregator will output 1 bundle per rowId, each containing an array of files.

Step 4) Gemini runs once per row

Connect Gemini after the Array Aggregator and map the aggregated array of files/images into Gemini.

Quick sanity checks

  1. Open an execution and inspect a single bundle coming out of the images Iterator

    • Do you actually see rowId in that bundle?

    • If not, grouping cannot work.

  2. Check the Array Aggregator output

    • Even if it shows N operations, does it output 1 bundle per row?

    • If it outputs N bundles, then rowId is missing/empty/unique each time.

If you share what your “images” array looks like (a sample bundle shape, no sensitive data), I can suggest the exact transformation needed to carry rowId through the 2nd iterator.

11

As you can see, I set the param in the second iterator (iterating through the array of images called JqdXb), and HTTP module using the previous iterator output value URL called value, then group by rowID in the 3rd pic, how do I even achieve the step 1 you mentioned, thanks for your help

image
image1938×1212 224 KB

image
image1990×1208 261 KB

image
image1968×1400 335 KB

12

You’re not fully solved yet — your setup looks close, but we need to confirm where the grouping breaks.

From your screenshots, referencing 16.$rowID in the Array Aggregator should work as long as that value is present and consistent for every HTTP bundle in the same outer row loop.

1) First quick check (most important)

Run once and open the Array Aggregator output:

  • Do you get 1 output bundle per row (each bundle contains an array of files)?

  • Or do you still get 1 output bundle per image?

Also make sure Gemini is mapped from the Array Aggregator output, not from the HTTP module directly. If Gemini still maps HTTP fields, it will run N times.

2) If the Array Aggregator still outputs N bundles

That usually means the “Group by” expression is evaluating differently per image bundle (often because rowID is missing/empty in the inner context).

In that case, do Step 1 by explicitly attaching the rowId to each image before iterating:

Add a module before the 2nd Iterator (Tools → Set variable, or JSON/Compose):
Create a new array like:

imagesWithRow = map(16.JqdXb; toCollection("rowId"; 16.$rowID; "url"; item))

Then:

  • 2nd Iterator Array = imagesWithRow

  • HTTP URL = 32.url

  • Array Aggregator Group by = 32.rowId (use the iterator output, not module 16)

This guarantees every image bundle carries the rowId, so grouping is deterministic.

3) Optional tip

In the Array Aggregator, you can aggregate only what Gemini needs (usually the file Data and filename) and skip headers/status to reduce payload.

If you can share 1 run screenshot of the Array Aggregator output bundles, I can tell immediately whether grouping is working or if it’s a mapping issue in Gemini.

13

Hi @bill255203 - you don’t actually need to group by rows at all, here’s a simpler solution:

#1 Change the Source module of your aggregator to the iterator before the HTTP module:

image
image2319×933 232 KB

#2 Remove the grouping by rows from the Group by field (leave it blank)

#3 Gemini will trigger once per row (because the initial iterator calls Gemini for each row). If you need to send Gemini the row ID for context, you can map it directly from the row iterator (module 6 in my screenshot)

You can also try using the “Explain flow” feature to get a better feel of how objects get iterated and aggregated in Make:

2026-01-08-05-39-q80Sc4n_500x223
2026-01-08-05-39-q80Sc4n_500x223500×223 7.05 KB

Cheers,
Sierra

14

I’d also encourage community members to not use AI to provide solutions (at least not without manual testing) - AI does not yet understand the nuances of Make well enough to provide solutions.

2 Likes
16

You’re absolutely right, @SierraV, and thank you for pointing that out. It’s actually in our Community Guidelines as well. AI very confidently hallucinates false information about Make, and will send users down non-existent rabbit holes. So we fully agree :slight_smile:

4 Likes
17

Hi everyone,

I’m working with Make + Google Vertex AI (Gemini) and trying to send multiple images in a single Gemini request.

After the Array Aggregator:

  • I correctly get one bundle

  • Inside it, I have an array with multiple records, each containing binary image data (base64-ready)

Problem:
When I build the Gemini request body, I map the aggregated array into the request, but Gemini only receives one image (it behaves as if only the first image is included).

What I tried:

  • Using the Array Aggregator output inside inline_data.data

  • Using base64(aggregatedArray[].Data)

This results in only one image being used, even though the aggregator clearly contains multiple items.

What I want:
I want the final request sent to Gemini to look like this:

"parts": [
  { "text": "prompt text" },
  { "inline_data": { "mime_type": "image/png", "data": "BASE64_1" } },
  { "inline_data": { "mime_type": "image/png", "data": "BASE64_2" } }
]

Question:
What is the correct way in Make to:

  • Aggregate multiple HTTP image downloads

  • And then expand that aggregated array into multiple inline_data objects inside contents[0].parts, instead of collapsing to a single value?

Is there a specific mapping pattern or structure required so Make expands the array into multiple sibling parts items?

Thanks in advance!

image
image2334×1098 178 KB

image
image1650×1410 225 KB

image
image1920×1346 283 KB

18

Hey there,

You are actually mapping the data item from the array and by default Make pulls the first item from the array unless you specify the orderondex of the item you want between the square brackets.

Don’t map the .data item instead map only the array.

Or if you only want to send the data, use the map() function to get a primitive array with only the data first and send that.

19

Thanks for the explanation

Just to confirm, are you suggesting that in the Gemini request body I should map the entire aggregated array (the array of image objects) directly into the data param in the image, instead of mapping array[].data, I’m pretty confused now

I tried mapping the full array, but it doesn’t seem to serialize correctly in the Gemini request body.

Could you please provide concrete instructions on:

  1. Exactly which field from the Array Aggregator output should be mapped into the Gemini or how should I reconstruct my body request

  2. Whether themap() function should be used at, and if so, the exact expression

  3. A minimal example of the final Gemini request body as it should appear in Make

That would help me align the structure correctly.

20

@SierraV @Stoyan_Vatov I hope you guys are doing well. I’ve gotten to this stage of building the flow in Make.com, and I was wondering if you could kindly guide me on the next steps. I can also share screenshots or the current setup for context. Thank you so much for your time and help.

21

Yeah share a screenshot of what you have at the moment and what is not working?

22

I think I’m still not fully understanding how your suggested mapping works in my scenario, and my original question is still the same: I’m getting two HTTP calls (two bundles) for two images in a single operation (this part is done as desired), but I need to stuff it in the Gemini request body so Gemini can see both images together and return one response. The screenshots are in the previous comments above, thanks a lot

23

Hi @bill255203 , could you paste the whole JSON from your Vertex module (from “Body”) here?

You can replace your prompt text with "<prompt here>" or something, I just need to see the structure of the JSON you’re working with.

Thanks!