Make.com guide

Delay a Make workflow without losing the ability to cancel it.

For a short, unconditional wait, Make’s native scheduling patterns may be enough. The harder case is a callback that should run hours or days later but disappear when the customer replies, pays, books, upgrades, or completes the step first.

Try a live webhook Read the API quickstart

API request

HTTPS only

curl -X POST https://webhookscheduler.com/api/v1/schedule \
  -H "Authorization: Bearer wh_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://hook.eu1.make.com/YOUR_WEBHOOK",
    "runAt": "2030-01-15T09:00:00.000Z",
    "body": {
      "event": "invoice.follow_up",
      "invoiceId": "inv_123"
    },
    "reference": "invoice:inv_123",
    "idempotencyKey": "invoice:inv_123:follow-up"
  }'

No due-job poller

Schedule the future callback once instead of running a Make scenario repeatedly to scan for work that is due.

Cancel on customer action

Keep the returned job ID with the business record, then cancel the pending callback when a reply, payment, booking, or status change arrives first.

Visible delivery history

See whether the callback is pending, canceled, delivered, retrying, or failed without reconstructing the state from multiple scenario runs.

The awkward Make pattern

A delayed client workflow often needs more than “wait, then do something.” An invoice reminder should not fire after payment. A lead follow-up should disappear after a reply. An onboarding nudge should stop when the user completes the step.

You can model this with a Data Store plus another scenario that periodically looks for due rows. The tradeoff is that scheduling, claiming due work, retry behavior, cancellation, and delivery history become infrastructure you now own inside Make.

A simpler two-event flow

On the first event, use Make’s HTTP module to call Webhook Scheduler. Send the future time, the Make webhook URL you want called later, and the payload. The response includes the job ID. Store that ID alongside the invoice, lead, booking, trial, or other business record.

On the second event — for example a payment, reply, booking, or status change — call POST /api/v1/jobs/{jobId}/cancel. If the job is still pending or retrying, it is canceled before the future callback is delivered.

What stays in Make

Keep the business logic in Make. Make still decides what should happen when the delayed webhook arrives, and your existing CRM, Airtable, monday.com, Stripe, email, or database modules still own the client state.

Webhook Scheduler only owns the future HTTP delivery lifecycle: scheduling, cancellation, retries, status, and the attempt trail. It is deliberately not another workflow builder.

When this pattern is worth using

Use an external scheduled webhook when the delay is long enough to outlive the current scenario, when customer state can make the action obsolete, or when you need a clear answer to “did this callback actually run?”

Common examples are invoice and dunning reminders, lead nurture, appointment follow-ups, trial-expiry nudges, onboarding steps, renewal notices, and delayed client API callbacks.

Try the same pattern without an account first

The live playground lets you schedule a real webhook before creating a workspace. If the pattern fits your Make build, continue with the automation agency guide or the API reference.

FAQ

Does Webhook Scheduler replace Make?

No. Make remains the workflow engine. Webhook Scheduler only holds and delivers the future HTTP callback, then Make continues the workflow when its webhook receives that request.

Why not just use a delay or scheduled scenario in Make?

If the wait is simple and unconditional, that can be the right solution. A scheduled webhook becomes useful when the pending action must be cancelable, independently retryable, and visible after the original scenario has finished.

What do I store in Make?

Store the Webhook Scheduler job ID with the business record that owns the delayed action. That ID is what you use to cancel the pending callback later.

Can I cancel after delivery starts?

No. Cancellation applies while a job is pending or retrying. Once processing has started, a request already in flight cannot be retracted.

Ship delayed webhooks without maintaining scheduling infrastructure.

Start with the free plan, test a real delivery, then upgrade when the workflow becomes production critical.

Try a live webhook