Experiencing replay attacks?

[Peter_Mienes]

What is your goal?

Have Make send information to Zoho

What is the problem & what have you tried?

I have a scenario that passes payment information received from Mollie to Zoho: Mollie triggers a webhook in Make, Make enriches the information, and Make calls a Zoho webhook/API.
After the first call (for a certain payment) I am experiencing ‘replays’: Zoho receives exactly the same JSON a couple of times more. This looks like a replay attack to me, and I’m wondering what I can do to prevent this.

Error messages or input/output bundles

n/a

[Stoyan_Vatov]

Hey Peter,

check the scenario history and see how many times the modules are getting triggered per different item.

Also, what is doing the enrichment and how? Can you show some screenshots of the scenario and how it works?

[Peter_Mienes]

Hi Stoyan,

Thanks for your message. Yes, I checked the scenario history and I can see that the last scenario execution was at 17:17:48.
The Zoho webhook/API was called at 17:18:19. That’s OK. But it was called again at 17:53, 17:55 and 17:56, with exactly the same JSON being presented to the Zoho webhook/API.

Here’s a screenshot of the scenario to illustrate the enrichment. When Mollie calls the Make webhook, it only provides a payment link id. First there’s a sleep of 30 seconds to allow some time for Mollie to get it’s administration in order. Then, based on the payment link id, there’s a HTTP request to Mollie to get information about the payment. Following that, a HTTP request is done to Mollie to get information about possible refunds that were done. The result is then sent to Zoho by calling a Zoho webhook, and an informational row with data is added to a Google sheet.

I’m not sure how to prevent the seemingly replay attacks that take place after the initial call of the Zoho webhook.
What I can think of is:

• adding a date/time field to the JSON so that Zoho can check whether it has already received the JSON recently
• adding an MD5 hash based on the Amount fields to detect tampering with the numbers

Thanks

[Stoyan_Vatov]

Ok but is it the same webhook being received several times in a row? The entire scenario running again and again on the same data? Or is it one execution inside of which the Zoho module is being called several times?

If its the first case - you can store what was received already in a data store and then check if this was already processed. You can also check on Mollie’s side why its sending the same webhook several times in a row.

If its the second - send a screenshot of the execution history so we can see what is causing the retrigger.

[Peter_Mienes]

it’s the second: one scenario run that causes (in the case that I scetched) the Zoho webhook to be called 4 times. Here’s a screenshot of the history:

And here are the details:

So the scenario was executed (once) at 17:17:48 and at the end of the scenario a HTTP request for the Zoho webhook was done (once). Following that, out of the blue, the Zoho webhook was called another three times.

[Stoyan_Vatov]

Ok so its a third different case. Cause it looks like the scenario executed correctly and ran only once.

Can you check the configuration of the module that does the call to Zoho and what it looks like?

[Peter_Mienes]

This is the HTTP request that calls the Zoho webhook:

thanks

[Stoyan_Vatov]

And this same data is being received 3 times?

Man sorry, I hate Zoho’s documentation with a passion. Is it this endpoint you are trying to hit?

[Peter_Mienes]

Yeah, 3 times, a couple of days ago it also happened a number of times. It’s a custom function configured as an API.

It’s a pity that Zoho doesn’t provide a log of incoming API calls specifying the originating IP-address.

Anyhow, I’m pretty sure that it’s a replay attack. I have created quite a few webhooks in Zoho and this is the first time that I’m experiencing this phenomenon.

I am now having Make create a MD5 hash for relevant fields and checking that in the Zoho function. This way allows me to detect illegitimate changes.

[mszymkowiak]

Hello,

37 seconds for that simple scenario is quite a long time.
Try to run the scenario manually and focus on which module takes so long to process.

In new HTTP modules under advanced settings, you can specify a timeout. Try to extend and see if that helps.

Also- probably that’s not your case right now but be aware that Make implemented exponential backoff feature that can not be managed by end user.

Disable automatic reprocessing on failure (scheduled scenario)

Hello, Make.com quietly added an exponential backoff feature in ~February 2025. You can learn more here: Exponential backoff - Help Center I submitted a suggestion via the suggestion portal to make it optional, but it hasn’t received any upvotes yet ( ). Personally, I think users should be able to decide whether Make handles errors without their knowledge. I know this feature is designed for non-tech people to help them, but in advanced workflows or complex business scenarios …

[Donald_Mitchell]

@mszymkowiak

37 seconds for that simple scenario is quite a long time.
Try to run the scenario manually and focus on which module takes so long to process.

I think that sleep at the beginning is 30 seconds

@Peter_Mienes

First there’s a sleep of 30 seconds to allow some time for Mollie to get it’s administration in order.

[Peter_Mienes]

Hi, thanks for your message. The execution time of this scenario is cause for a large part by the 30 seconds sleep that I built in. This is necessary to allow Mollie some time to get it’s administration in order: at the time the scenario is triggered by Mollie, it appears that Mollie has it’s administration not yet in order: payment value fields that should be filled are still 0.00.