Wait longer than 5 minutes in Make: delay a scenario for days.

Fastest: copy a template

• Trial reminder

  Day 6, cancelled on upgrade

  ScheduleCancel

• Invoice follow-up

  Day 7, cancelled on payment

  ScheduleCancel

• Review request

  Day 14, cancelled on refund

  ScheduleCancel

Or build it yourself

1. 1

   Step 1: Create scenario 2 and copy its address

   1. In Make, create a new scenario. Name it, for example, Invoice follow-up (runs later).
   2. Add the module Webhooks → Custom webhook.
   3. Click Add to create a webhook, name it Resume after delay, and click Save.
   4. Click Copy address to clipboard and keep the address at hand: you paste it in step 3.
   5. Save the scenario. Leave it off for now.

   When it worked: you have an address that starts with https://hook. and ends with a long code, for example https://hook.eu1.make.com/k3f9….
2. 2

   Step 2: Get your Webhook Scheduler API key

   1. Create a free account (or sign in).
   2. Open Dashboard → API keys, name the key Make, and click Create key.
   3. Copy the key. It starts with wh_live_ and is shown only once.

   When it worked: the page shows Copy your key now. Below it, the Make / n8n view repeats the settings of the next step with your key already filled in.
3. 3

   Step 3: Create scenario 1 with an HTTP module

   Open the scenario that should start the wait, or create a new one for the test. After its trigger, add HTTP → Make a request and fill it in field by field:

   HTTP → Make a request

   Authentication type

   No authentication

   URL

   https://webhookscheduler.com/api/v1/schedule

   Method

   POST

   Headers

   Click Add a header, then fill the two fields below.

   Headers → Name

   Authorization

   Headers → Value

   Bearer wh_live_YOUR_KEY, with your key in place of wh_live_YOUR_KEY. Keep the word Bearer and the space.

   Body content type

   application/json

   Body input method

   JSON string

   Body content

   The JSON below.

   Parse response

   Yes

   Body contentjson

   Copy

   {
     "url": "https://hook.eu1.make.com/YOUR_SCENARIO_2_ADDRESS",
     "runAt": "{{addMinutes(now; 2)}}",
     "reference": "invoice:test-123",
     "body": {
       "invoiceId": "test-123",
       "email": "test@example.com"
     }
   }

   • url: replace the example with the address you copied in step 1.
   • runAt: two minutes from now, for the test. When you paste it, Make turns {{addMinutes(now; 2)}} into a formula and sends the date in the format the API expects. You switch it to three days in step 7.
   • reference and body: test values for now. Scenario 2 receives body as its data.

   Different labels in your HTTP module? Any version works: a POST with the header above and this JSON as an application/json body.

4. 4

   Step 4: Send a test that arrives in 2 minutes

   1. Open scenario 2 and click Run once. It waits for data.
   2. In another browser tab, open scenario 1 and click Run once. If your trigger needs an event (a new invoice...), create a test one.
   3. In scenario 1, click the bubble above the HTTP module and open the output. You will see Status code 201 and, under Data, an id and status: PENDING (Scheduled in the dashboard).
   4. Wait about two minutes. Scenario 2 runs: click the bubble above its Custom webhook and you see invoiceId and email.

   When it worked: scenario 2 received the bundle. Make now knows its fields, so in scenario 2’s next modules you can map invoiceId and email from the Custom webhook.

   Another status code? 401 means the key or header is wrong; 400 means the JSON or the url is invalid (the response says which field); 403 is a plan limit (API errors).

   If scenario 2 stopped waiting before the call arrived, Make keeps the call in the webhook’s queue: click Run once again to process it.

5. 5

   Step 5: See it Delivered

   Open Dashboard → Jobs. The top row goes to hook.eu1.make.com/… (your region may differ) with the status Delivered (SUCCESS in the API). Click it: the attempt shows HTTP 200 and Make’s answer, usually Accepted.

   When it worked: the job is Delivered. Your first delayed Make scenario works.

   Failed with 410 or 404? The address in url is wrong or the webhook was deleted: copy it from scenario 2 again (HTTP 410).

6. 6

   Step 6: Turn both scenarios on

   In scenario 2, switch the scenario ON (its schedule stays Immediately as data arrives). Then switch scenario 1 on. From now on, every trigger in scenario 1 schedules a call, and scenario 2 runs on its own when the call arrives.

   When it worked: both scenarios show ON in your scenario list.
7. 7

   Step 7: Switch to the real delay and real data

   In scenario 1, edit the HTTP module’s Body content:

   1. Replace {{addMinutes(now; 2)}} with {{addDays(now; 3)}}.
   2. Replace each test value with a field from your trigger: select test-123 (keep the quotes around it), delete it, and pick the invoice ID in the mapping panel. Do the same for the email and for the reference, after invoice:.

   Map IDs, not free text: a double quote breaks the JSON, and reference accepts letters, digits and : . _ / - only.

   For a fixed time instead, such as 7:30 tomorrow in the scenario’s time zone, use {{setHour(setMinute(addDays(now; 1); 30); 7)}}.

   When it worked: the next real trigger creates a job that Jobs shows as Scheduled (PENDING in the API), three days ahead.
8. 8

   Step 8: Optional: cancel the follow-up when the customer pays

   In the scenario that handles the payment (or reply, or booking), cancel the call that is still waiting. The cancel templates above do this for you. By hand, two ways:

   Option A: with the job id

   In scenario 1, save the HTTP module’s Data → id with the invoice (a Data store, your CRM, a sheet). In the payment scenario, add one HTTP module:

   HTTP → Make a request · cancel by id

   URL

   https://webhookscheduler.com/api/v1/jobs/JOB_ID/cancel, with the stored id mapped in place of JOB_ID

   Method

   POST

   Headers → Name

   Authorization

   Headers → Value

   Bearer wh_live_YOUR_KEY, with your key in place of wh_live_YOUR_KEY. Keep the word Bearer and the space.

   Body content type

   Empty

   Option B: with your own reference

   No id to store: find the open jobs by reference, keep those that can still be canceled, then cancel each.

   1 · HTTP → Make a request · find

   URL

   https://webhookscheduler.com/api/v1/jobs

   Method

   GET

   Headers → Name

   Authorization

   Headers → Value

   Bearer wh_live_YOUR_KEY, with your key in place of wh_live_YOUR_KEY. Keep the word Bearer and the space.

   Query parameters

   reference = invoice: followed by the mapped invoice ID; state = open

   Parse response

   Yes

   2 · Flow Control → Iterator

   Array

   Data → jobs from module 1

   Filter on the link from the Iterator to module 3

   Label

   Can be canceled

   Condition

   the Iterator’s status, Equal to, PENDING

   Add OR rule

   the Iterator’s status, Equal to, RETRYING

   In short: Status equals PENDING or RETRYING. A PROCESSING job is being sent right now and can’t be canceled, so the filter skips it instead of letting the cancel fail.

   3 · HTTP → Make a request · cancel

   URL

   https://webhookscheduler.com/api/v1/jobs/JOB_ID/cancel, with the Iterator’s id mapped in place of JOB_ID

   Method

   POST

   Headers → Name

   Authorization

   Headers → Value

   Bearer wh_live_YOUR_KEY, with your key in place of wh_live_YOUR_KEY. Keep the word Bearer and the space.

   When it worked: the cancel module answers 200 with status: CANCELED (Canceled in the dashboard), and Jobs shows the webhook as Canceled.

   A webhook can be canceled while it is Scheduled (PENDING) or Retrying (RETRYING). A cancel can still cross a delivery that is starting, so let scenario 2 check the invoice is still unpaid before it emails anyone. Every scheduled webhook counts toward your monthly quota, canceled ones included: on Free, 100 a month.

Why not Sleep or a Data Store

What the free plan covers

Questions