How to Do Polling with Make.com (formerly Integromat)

Can we do polling in Make.com?

So, you’re trying to set up polling in Make.com, and you’re finding it impossible. Well, it actually is impossible. But don’t worry — there’s a workaround.

Before we dive in, make sure to download the template I use in this post. Of course, it’s free.

https://get-blueprint.lemonsqueezy.com/buy/20c511f7-5fb7-45c4-aa83-ede0a94c4bef

Unfortunately, I have no idea what API you are working with, so you will need to adjust the template by replacing some values, but you will get the idea of what we need to be doing.

Template looks like this

Or this

Repeater isn’t enough

At first glance, it might seem possible to do polling using a repeater, so let’s try that approach first and see where the problem lies.

In most programming languages, you can say something like, “while this condition is true, keep doing this and that.” However, in Make.com, you can only specify how many times the repeater module should repeat the following branch. And once the repeating branch starts, the repeat count *cannot* be changed. For example, you can set it to 10, 20, or 30 iterations, but you can’t modify the count after it starts running. This means that even if you get the result from the API you are working with during polling, you cannot stop the branch. And that’s the problem of simply using a Repeater.

You cannot change the Repeats once the Repeater has started.

Luckily, there’s a workaround

I should give a shout-out to someone who shared this workaround on social media, but I lost track of his post. If you’re reading this and it was your idea, please reach out so I can credit you here.

Purposely Cause an Error

So, how do we stop a branch once we’ve retrieved the result? The answer: intentionally cause an error.

See the error handler at the end?

Here’s how it works: after the “Get Result” module in your polling flow (e.g., the module used to fetch a job’s status), you create an error on purpose. When polling, the flow typically involves a “Start Job” request followed by a “Get Result” module. We need to introduce an error after the “Get Result” module.

To do this, set up a filter right after the “Get Result” module. If the status is something like “still processing” or “not finished” (depending on the API endpoint you’re working with), instruct the flow to loop back to the repeater and continue making “Get Result” requests until the job is complete. Once the job is done, the flow will pass through the filter.

Set a filter after your Get result module (screenshot from the template)

After that, you can add any module you want. I usually use the “Parse JSON” module because it’s an easy way to generate an error by intentionally passing invalid JSON. And that’s the key step in this workaround. Finally, we add a Commit error handler to the Parse JSON module so that Make won’t turn off the scenario.

Any error works (doesn’t have to be a Parse JSON module)

Error caused by the Parse JSON module which will be handled by the following Commit module

Things to Keep in Mind

1. Operation Consumption

You can poll as often as you want, but keep in mind that without a “Sleep” module (e.g., a delay of 5–10 seconds), you’ll quickly consume a large number of operations. If you’re running this automation in bulk, you’ll need to strategize carefully to avoid excessive usage.

2. Limitation

Since we’re creating an error, the scenario will stop once it reaches the Commit error handling module. This means you can’t add more branches that you need the workflow to move on to. Because of this limitation, this workaround should not be used as a part of a large scenario.