Next.js on Vercel

Schedule delayed HTTP jobs from Next.js without maintaining a worker.

Vercel gives you strong primitives for cron, queues, functions, and workflows. Webhook Scheduler fits the smaller product case: your Next.js app needs to send one public HTTPS request later, with retries, cancellation, and a delivery log already attached.

Create a test job Read the implementation guide

API request

HTTPS only

const runAt = new Date(
  Date.now() + 24 * 60 * 60 * 1000
).toISOString();

await fetch('https://webhookscheduler.com/api/v1/schedule', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'x-api-key': process.env.WEBHOOK_SCHEDULER_API_KEY!
  },
  body: JSON.stringify({
    url: 'https://your-app.com/api/jobs/onboarding-follow-up',
    method: 'POST',
    runAt,
    body: {
      event: 'onboarding.follow_up',
      userId: 'user_123'
    },
    idempotencyKey: 'user_123:onboarding_follow_up'
  })
});

One POST from your app

Create a delayed HTTP job from an API route, Route Handler, Server Action, or trusted backend function.

Retries and logs included

Failed deliveries keep status codes, errors, timestamps, and retry state without another worker table.

Cancel when state changes

Save the returned job ID and cancel pending follow-ups when the user acts before the delivery runs.

The wedge is not replacing Vercel

Vercel Cron is good for fixed recurring tasks, Vercel Queues are good when you want queue semantics, and Vercel Workflows are good when the workflow itself should be durable code.

A lot of product jobs are simpler than that. A user signs up, an invoice fails, a trial is about to end, or an integration needs a callback later. The output is just an HTTPS request, but the operational details around that request still matter.

Where cron polling gets messy

The first version is usually a database column and a cron route that polls every minute. Then production asks for retry backoff, duplicate-send protection, cancellation, endpoint errors, support visibility, and a way to answer “did it actually run?”

Webhook Scheduler moves that delivery layer out of your Next.js app. Your app keeps the product state. The scheduler owns the timestamp, dispatch, attempts, retry history, and delivery outcome.

When this is the right fit

Use Webhook Scheduler when the work can be represented as a future HTTPS request: onboarding follow-ups, billing recovery, no-code callbacks, delayed integration syncs, product reminders, or post-purchase lifecycle events.

Keep your own queue or workflow system when the job needs local compute, private network access, long-running code, or tight coupling to internal services. The product is intentionally focused on scheduled public HTTPS delivery.

A simple production pattern

Call the scheduling API only from server-side code. Store the returned job ID next to your user, invoice, or workflow record. If the underlying state changes before the delivery time, cancel the job.

The receiver should still be idempotent. Retries are correct when the sender cannot confirm success, so your endpoint should safely handle a repeated request for the same business event.

From test to paid usage

Start with one dashboard-created test delivery. The built-in receiver proves the scheduling path before you point the job at your own endpoint.

Once a real workflow is carrying production callbacks, upgrade for higher monthly volume, deeper automatic recovery, more API keys, and longer scheduling windows. The pricing page shows the current plan limits.

FAQ

Is this a Vercel Cron replacement?

No. It is a focused layer for delayed public HTTPS deliveries created at runtime. Use cron for fixed recurring schedules.

Why not use a queue?

Use a queue when you want to own consumers and internal compute. Use Webhook Scheduler when the job output is simply a future HTTP request and you want retries, cancellation, and logs already handled.

Can I schedule a Next.js API route?

Yes. Schedule the public HTTPS URL of the route, keep the API key server-side, and validate the callback inside the receiver.

Ship delayed webhooks without maintaining scheduling infrastructure.

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

Create a test job