Make.com Iterator vs Array Aggregator

Data in Make.com does not always arrive in the shape you need to work with it. An API returns an array of fifty records in a single bundle, but the module you need to run next only knows how to handle one record at a time. Or the reverse: you have processed several individual items separately and now need them combined back into one array to send somewhere as a single record. The Iterator and Array Aggregator are the two modules built specifically for these opposite problems, and understanding which one you need, and how they work together, is one of the more useful things to get comfortable with early in Make.com.

What an Iterator Does

An Iterator takes a single bundle containing an array and splits it into multiple individual bundles, one per item in the array. If an API call returns fifty product records as one bundle, the Iterator converts that into fifty separate bundles, each flowing through the rest of the scenario individually. This matters because most modules in a scenario only operate on one bundle at a time, so anything after the Iterator effectively runs once per item automatically, without you needing to build separate handling for each one.

The Iterator only works on arrays. If your data is not shaped as an array already, you sometimes need to construct one first, using a function or an aggregator elsewhere in the scenario, before the Iterator has something to split.

What an Array Aggregator Does

An Array Aggregator does the opposite: it collects multiple separate bundles and combines them back into a single bundle containing an array. If you have iterated through fifty items, transformed each one, and now need to send all fifty back to a destination as one combined record rather than fifty separate API calls, the Aggregator is what reassembles them.

Iterator Example

A common real case: an email arrives with several attachments. The email itself is one bundle, with the attachments represented as an array within it. Running an Iterator on that array splits it into a separate bundle per attachment, letting you process, rename, or upload each file individually in the modules that follow, rather than trying to handle all the attachments at once inside a single bundle.

Aggregator Example

The reverse case: you have uploaded several files to Google Drive individually through an Iterator, and each upload returns a shareable URL. Rather than writing fifty separate rows to a spreadsheet or fifty separate records to a database, an Array Aggregator combines all those URLs into one array, which you then map into a single field, an Attachments column in Airtable, for instance, producing one clean record with all the links stored together instead of fifty scattered rows.

Using Them Together

The two modules are frequently used as a pair: Iterator splits the array, some processing happens on each individual item, and an Aggregator collects the results back together at the end. You can also nest this pattern, iterating through an aggregated result again for a second pass, useful when each item in your first array itself contains a sub-array you also need to loop through individually.

Common Mapping Errors

The single most common mistake with Array Aggregator is misconfiguring the source module setting, which tells the Aggregator which module's output it should be collecting bundles from. If you select a source module that itself runs multiple times in the scenario, rather than one that runs exactly once, you end up with multiple separate aggregated arrays instead of the single combined array you actually wanted. A module that runs once, a webhook trigger or a single API call, is usually the correct source selection when you want everything downstream aggregated into exactly one result.

Variables also behave differently inside an Aggregator than they do in a normal linear flow, which catches people off guard the first time they try to reference something from earlier in the scenario while inside the aggregation step. Test the aggregation output directly after building it, rather than assuming the mapping is correct, since a subtly wrong array structure often does not throw an obvious error, it just produces a shape the next module cannot use correctly.

Performance Considerations

Each item passing through an Iterator counts as its own set of operations for every module it flows through afterward, which is worth keeping in mind for scenarios processing large arrays, fifty items through five downstream modules is two hundred fifty operations, not fifty. Make.com Scenario Too Slow? and the general operations discipline covered there applies directly here: iterating through a genuinely large array without a real reason to process each item individually can be an expensive way to move data compared to a batched approach where the target API supports it.

Decision Checklist

Reach for an Iterator when you have one bundle containing an array and need to process each element separately, individual transformations, individual API calls, individual filters applied per item. Reach for an Array Aggregator when you have multiple separate bundles that need to become one combined record or array before continuing. If you are doing neither, moving data through without needing to split or recombine it, you likely do not need either module at all.

If you are building a scenario that handles webhook data with variable-length arrays, such as multiple line items in an order or multiple attachments on an incoming message, Make.com Webhook Tutorial covers the trigger setup this pattern typically sits downstream of.

If a Make.com scenario is producing unexpected or duplicated data because of an Iterator or Aggregator misconfiguration, or you need help structuring a scenario that processes arrays correctly, that is exactly the kind of scenario work I take on for clients. Book a free 30-minute call and bring the scenario, and we can work through the data structure together.

Frequently Asked Questions

What is an iterator in Make.com?

A module that splits a single bundle containing an array into multiple individual bundles, one per item, letting everything downstream process each element separately rather than handling the whole array at once.

What is an array aggregator in Make.com?

A module that collects multiple separate bundles and combines them back into a single bundle containing an array, the opposite operation of an Iterator, used when you need several individually processed items reassembled into one combined record.

What is the difference between iterator and aggregator?

An Iterator splits one array into many bundles. An Array Aggregator combines many bundles back into one array. They are inverse operations, frequently used together in the same scenario, splitting first, processing, then recombining.

Can I use an iterator and aggregator together?

Yes, this is the most common pattern: Iterator splits the array, downstream modules process each item individually, and an Array Aggregator collects the processed results back into a single combined array or record at the end.

Why is my Make array aggregator empty?

Almost always a source module misconfiguration, pointing the Aggregator at a module that either does not produce the array of bundles you expect, or one that runs multiple times when it should run once, producing multiple partial aggregations instead of one complete result.

Which is faster, iterator or aggregator?

Neither is inherently faster in isolation, they serve different purposes. What affects speed and operations cost is how many items flow through the Iterator and how many downstream modules each one triggers, since each item's pass through subsequent modules counts as its own operation.

If you would rather have this fixed than fix it yourself, I take on Make.com scenario architecture work through Fiverr.