Scheduled HTTP requests

How to schedule an HTTP request for later.

If the future task is an outbound HTTP call, you do not always need a full queue worker. A delayed webhook API can store the request, run it later, retry failures, and keep delivery evidence.

Schedule a webhook Read API docs

API request

HTTPS only

curl https://webhookscheduler.com/api/v1/schedule \
  -H "Authorization: Bearer wh_live_xxx" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://api.example.com/internal/follow-up",
    "method": "POST",
    "runAt": "2026-06-04T09:00:00.000Z",
    "body": {
      "event": "follow_up_due",
      "customerId": "cus_123"
    },
    "idempotencyKey": "follow_up:cus_123:2026-06-04"
  }'

Future HTTP calls

Schedule POST, GET, PUT, PATCH, or DELETE requests to public HTTPS targets from your backend.

No polling loop

Avoid writing a cron scanner, stale-lock recovery, retry table, and support dashboard for simple delayed callbacks.

Delivery history

Keep status, latency, attempts, response body snippets, errors, and final state visible from one dashboard.

The simple pattern

Your app decides that an HTTP request should run later. Instead of inserting a row and hoping a cron worker finds it, your backend calls a scheduling API with the target URL, method, JSON body, run time, and idempotency key.

When the time arrives, Webhook Scheduler dispatches the request, records the attempt, and retries temporary failures according to plan limits.

Use cases

Scheduled HTTP requests are useful for trial follow-ups, delayed onboarding steps, invoice recovery, subscription reminders, customer lifecycle callbacks, no-code webhook triggers, Discord announcements, CRM syncs, and cleanup callbacks.

If the job needs arbitrary compute, a queue may still be the right tool. If the job is a future HTTPS delivery, a delayed webhook API keeps the implementation smaller.

What to include in the request

Include a public HTTPS target, method, payload, run time, and a stable idempotency key tied to the business object. Keep API keys server-side and keep receiver-side processing idempotent.

The exact fields are documented in POST /api/v1/schedule.

Cron vs scheduled HTTP request

Cron is enough for fixed internal tasks. It becomes awkward when every customer needs a different future HTTP request with its own payload, retry history, cancellation state, and delivery log.

For a fuller comparison, read Cron Job Alternative for Scheduled Webhooks.

Reliability checklist

A reliable scheduled HTTP system should validate targets, cap payload size, avoid unsafe redirects, retry temporary failures, store attempts, expose logs, support cancellation, and prevent duplicate side effects with idempotency.

Webhook Scheduler is built around that checklist. See the security and reliability model for the safety details.

FAQ

Can I schedule an HTTP request without cron?

Yes. A delayed webhook API lets your backend create a future HTTPS request with a run time, payload, retries, and logs.

Is a scheduled HTTP request the same as a background job?

Not exactly. Background jobs run arbitrary compute. Scheduled HTTP requests are focused on future outbound HTTPS delivery to another system.

Can scheduled HTTP requests retry?

Yes. Webhook Scheduler can retry failed deliveries according to plan limits and records each attempt for debugging.

Ship delayed webhooks without maintaining queue infrastructure.

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

Schedule a webhook