Verify your first scheduled delivery on your own receiver

An interactive demonstration can make delayed HTTP delivery easier to understand. Connecting your application introduces a different question: can your own endpoint receive, authenticate and safely apply the intended action? Answer it with one harmless test record before connecting a customer-facing reminder.

Choose an outcome you can inspect

Use a test record in your application and define a small effect, such as recording when an integration check completed. Keep this separate from an actual customer notification. The exercise should leave evidence you can inspect without sending an email, taking a payment or changing a customer's access.

Write down three distinct observations: the schedule request returned a job ID, your receiver accepted an authenticated delivery, and the intended test effect was saved. A successful observation at one boundary does not establish success at the next. This distinction prevents a green scheduler status from concealing an application that accepted a request but discarded its work.

Prepare the receiving boundary

The API reference requires a public HTTPS destination. Use the final receiving URL rather than a page that redirects to login or another route. A development server on localhost is not a supported scheduling destination; a dedicated public test endpoint is a clearer integration target.

Keep the API key used to create jobs on your server. At the receiver, follow the documented signature procedure using the workspace's signing secret, the incoming timestamp and the exact raw request body. Do not parse JSON and then serialize it again to construct the signed input. Handle a missing or malformed signature as a failed authentication attempt, before trusting the resource identifier.

Only after authentication should the handler load the test record and check its current eligibility. An authenticated request can still refer to obsolete work. Make a durable event claim and the local test effect part of one database transaction, or use an equivalent atomic operation suited to your database.

Schedule one traceable request

The illustrative server-side request below schedules delivery one day from execution. Replace the receiver URL and example identifiers with your test setup. Use a future time appropriate to your test when adapting it; the example does not execute immediately or create your receiver for you.

Illustrative server-side example: this schedules delivery 24 hours from execution. Replace the environment variables and example record IDs, persist the returned job ID, and implement your own authenticated HTTPS receiver. The request follows the current API reference.

const apiKey = process.env.WEBHOOK_SCHEDULER_API_KEY;
const receiverUrl = process.env.REMINDER_WEBHOOK_URL;
if (!apiKey || !receiverUrl) throw new Error("Set the server-side API key and public HTTPS receiver URL.");

const response = await fetch("https://webhookscheduler.com/api/v1/schedule", {
  method: "POST",
  headers: { Authorization: `Bearer ${apiKey}`, "Content-Type": "application/json" },
  body: JSON.stringify({
    url: receiverUrl,
    method: "POST",
    runAt: new Date(Date.now() + 24 * 60 * 60 * 1000).toISOString(),
    reference: "integration:example-123",
    idempotencyKey: "integration-example-123-reminder-v1",
    body: { resourceId: "example-123" },
  }),
});
if (!response.ok) throw new Error(`Scheduling failed: ${response.status}`);
const job = await response.json();
if (!job.id) throw new Error("Missing scheduled job ID");
// Persist job.id with your business record before acknowledging this work.
console.log(job.id);

Save the returned job ID beside the local test record. If the response is lost or that local write fails, retry with the same scheduling idempotency key to recover the retained original job. Do not generate a fresh key simply because you cannot yet see a result in your application. A new key represents new scheduled work.

Inspect all three observations

Use the documented job inspection endpoint or dashboard to examine delivery attempts. An HTTP status, response body or connection error helps locate the boundary that failed. Check your receiver's corresponding record to establish whether the test effect actually committed; do not infer that from a scheduler status alone.

Keep responses and logs concise and free of credentials. A redirect response, rejected signature and unavailable database are different problems and need different fixes. Repeating the schedule request will not correct a receiver that rejects every delivery. If the handler accepts work for a separate worker, inspect that worker's durable result as another boundary in the exercise.

Repeat safely before adding real effects

WebhookScheduler is built by AllClearStack. Its documented delivery model permits duplicates, so test repeated authenticated delivery in your controlled environment and confirm that the test effect remains single. Also test an invalid signature and an obsolete record. Signature verification and business-event deduplication serve different purposes; neither replaces the other.

The limitation of this exercise is intentional: one successful test is evidence for that integration path, not a claim about sustained reliability. Before adding an external notification provider, define its idempotency and timeout-reconciliation behavior too. A local transaction cannot make an external message exactly once.

An existing database worker may be sufficient if it already provides the delayed work and visibility you need. Use the workflow guides to keep the responsibilities explicit whichever transport you choose.