Hi. Is it possible to have a webhook, that irrespective of how many times it is called externally, it only actually executes the modules a maximum of once every 5 minutes?
I have a scenario which does some checks on links, and if they’re still valid. These are triggered by Airtable updates. If you do multiple updates in a short while, this can be triggered say 50 times in a short span. In that case, I would like it to only be executed once.
Regards,
Karl
Hi Karl,
I’m not sure if there’s a better solution, but I would suggest using a custom variable as a filter (assuming pro plan or higher).
Let’s call it $scenarioA_triggered and set it to false
Have two scenarios. One should act as the trigger with a filter and a webhook (or Make module) to activate the main scenario, which holds the logic.
In your trigger scenario use $scenarioA_triggered equals false as a filter for sending the webhook to activate the main scenario.
In the main scenario, set $scenarioA_triggered to true during operation and then back to false when you’re done. You can add delays here as necessary to control how long it will wait. You can also have it wait before or after your logic. That is all up to you.
An alternative to this would be to create a third scenario that acts only as a timer for the filter variable. That might be overkill, but it would give you more control over the timer, particularly if your main scenario is long or unpredictable in duration.
Hope that helps!
EDIT:
Since you’re using Airtable, the “Watch Records” module should handle this partially for you anyway. It won’t return duplicate records, so if your record is running on a 5 min schedule then you shouldn’t have an issue. Hope that makes sense.
Hi @karlcassar
Snippet from the documentation which might answer your question
Source: https://www.make.com/en/help/tools/webhooks#scheduling-webhooks-processing
By default, when Make receives data on a webhook, your scenario executes immediately. If you don’t want to run your scenario immediately after a webhook receives data, you can schedule your scenario to process all webhook requests periodically.
When a scheduled webhook receives data, Make stores the data in the webhook’s queue. The whole queue is then processed every time your schedule criteria are met.
Glenn - Callinetic
This seems like a possible solution. One question related to this - is it possible to clear up the web queue every time an execution is complete? From what I’ve read from the article, you can set it to trigger say 1 execution per 5 minutes. However, if 50 calls are queued, this will continue triggering them one by one, so in this case it would be executing constantly for 50 x 5minutes. Basically in my use case, all calls are invalid once its processed as the links would have already been updated, and I would like to clear the queue each time. Then, if I get a new distinct webhook call after the scenario has executed, that one would call.
Hi Karl,
Do you mind briefly describing the scenario?
Do you make X number of Airtable updates and each updates triggers the webhook, which triggers the scenario? And instead of the scenario running every single time an update is made, you only want it to run max once every 5 minutes?
If that’s right, why couldn’t you just schedule the scenario to run every five minutes?
My use case is this - I have a Make scenario which refreshes Airtable records/primary key links, for reporting. This needs to be updated when something “happens”. If nobody access the system, or updates data - there is no need. So running it every 5 minutes would be a big waste, as the system is generally accessed mostly at the end of the month, and is used extensively for 1 - 3 days.
I would like that if say a user starts working on the system, Airtable would start pushing out calls to the webhooks when updates are done. As it is, Make ends up doing a lot of unnecessary updates as there is no need to do it say once per second. I would only want the link updates to be done once say every 5 minutes, not with each airtable push. So basically, the webhook call would be like “If webhook hasn’t been called in the past 5 minutes, execute, else ignore”. Of course, the 5 minutes is arbitrary, and I might decrease/increase this accordingly.
With the scheduling, Airtable might trigger 200 calls to the webhook, and if I set it to execute once ever 5 minutes, the queue would take 200 x 5 minutes to actually finish, whereas the 199 calls are technically useless.
Thanks for this context, this helps a lot.
Each update calling the webhook is a problem because it’s going to be at least one Op for Make to accept the request. The best you could do is just ignore the requests until it’s time to stop ignoring them and do some work, but that would still use at least one Op per AT change.
Perhaps you could leverage Airtable Automations here.
Create yourself an additional field, a simple check mark.
Use automations to check that box whenever a key change is made to a record and the links needs to be recalculated.
Create a second field, a formula that calculates how many minutes have elapsed since the last update to the record.
Finally, another automation that searches for all records where that checkbox is checked and the last update was 5+ minutes ago. If any are found, trigger your Make scenario.
The scenario could be modified to search Airtable records for the same parameters (checkbox checked and last updated 5+ minutes ago), do all the work you need done, then update those records and clear that checkbox field.
Hope this makes sense!
Hi @Donald_Mitchell . Thanks a lot for that suggestion using Airtable, it didn’t occur to me to think that way. I’ve now done a simple ‘WebhookScheduler’ table, which keeps track of the last executed time and last requested time for each webhook I want to schedule/rate limit. Once actually excuted in Make, Make updates the LastExecutedTime in Airtable. I’ve even done fields so I can choose the total seconds between executions, so I can rate limit/schedule differnet webhooks different.
Then, using an Airtable automation, once enough time has elapsed between last executed to now, if there is a request for a call, the call is made to Make. This way, it allows the app to be much more responsive than just say every 15 mins or every 30 mins. If anybody needs more info on the actual solution, just ask happy to share.
Very simple solution, thanks for your suggestion!