Enable/Disable my scenario's webhook on a schedule

:bullseye: What is your goal?

I’m looking to implement a controller-style approach to enable and disable a Make scenario based on defined time windows.

To clarify, I do not want to control execution frequency using the scenario’s internal scheduler. Instead, I need the scenario itself to be fully enabled or disabled depending on the time of day.

The reason for this is that the incoming webhook cannot be paused or controlled from the sending system. It will continue to send requests regardless of timing, so the only effective solution is to have the Make scenario completely disabled when it should not be processing data.

Required behaviour:

• Scenario enabled (active):
• Between 6:00 PM and 6:00 AM (the following day)
• All day on weekends

• Scenario disabled (inactive):
• All other times

I’m looking for guidance on the best practice or supported method to programmatically enable and disable a scenario based on these time windows (for example, via API or a separate controller scenario).

Thanks in advance for your help.

Best regards,
Michael

Hi Michael,

My recommendation would be to keep the scenario enabled and handle the time-window logic directly inside the scenario, right after the webhook trigger.

Make doesn’t support programmatically enabling or disabling a scenario based on time, so this is the most reliable approach. You can simply check the current day and time, and if the request falls outside your allowed window, stop processing and return an immediate response.

This keeps the webhook available at all times, while ensuring the scenario only does real work during nights and weekends.

Hope that helps.

Regards, Tony

1 Like

Hello @Michael_Robertshaw and welcome to the Make Community!

With Webhooks you can actually schedule the scenario to run on a frequency, doens’t have to be instantly. In the meantime, the webhook will continue to build its queue.

Use the scheduler pane to modify that - click “Immediately” and change it to something else.

You can also change the number of results that will be processed when it does run in the window.

Doesn’t sound like that will work for you in this case, but wanted to let you know!

For this issue, you can use another Scenario with Make modules to turn a scenario’s scheduling on and off.

The problem with this is that the data is lost and I believe the OP intends to have the data held until the next window in which it’s allowed to run.

Hi Gents!

First of all, thank you so much for your responses. All super helpful.

Believe it or not, losing the data when it’s inactive is what I’m looking for.

I have connected to a 24/7 live booking software (around 2000 reservations per day), so I’m trying to avoid my webhook being active at all in the “off” period because if it remains on, the workflow does not apply, yet it still listens and processes every reservation and in the reservation software, I am limited in when/how to send.

So Donald, I think your ‘Make: Turn on/off module’ would be the perfect solution. Would you mind sending a screenshot or steps on how that might look, please?

Alternatively, if I could prevent the data from queuing, that might also work. The workflow I have is working great; it’s just very credit-hungry to run in its current state.

Thank you so much, gentlemen!

Turning on/off the scenario won’t help because the hook will still queue and the minute the scenario turns back on it will process everything that was in the queue.

You could disable the actual hook, but that might cause the software calling the webhook to either continue retrying and/or eventually stop trying altogether, which isn’t ideal.

In that case, I think @avillarruel’s answer is the best.
You’d need to use a router and filters after the webhook to check the date/time and determine whether to accept the webhook and continue processing.
If not, use a Webhook Response to send back a 200/201 Status Code to let the booking software know it was accepted and doesn’t try to re-send, then in the scenario you just dump the data and wait for more.