Free Webhook Schedule API Endpoint

Schedule a delivery

curl -X POST https://aisenseapi.com/services/v1/webhook_schedule \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com/hook", "delay_seconds": 1200, "payload": {"job": 42}}'

{
  "ok": true,
  "schedule_id": "b4ee9fc4-e939-47d7-b522-1a68e553c546",
  "status": "scheduled",
  "fire_at_timestamp": 1787181214,
  "fire_at_datetime": "2026-08-19T23:13:34+00:00",
  "result_url": "https://aisenseapi.com/services/v1/webhook_schedule/b4ee9fc4-e939-47d7-b522-1a68e553c546",
  "expire_timestamp": 1787267614,
  "expire_datetime": "2026-08-20T23:13:34+00:00"
}

Keep the schedule_id. It is the only route back to the job, and there is no listing call that would find it for you. The result_url field saves you building that path by hand.

Give it a delay or a fire time

Two request fields set the moment. Send delay_seconds to count forward from now, or send fire_at as a unix timestamp to name an absolute instant. Pick one.

Field	Type	Description
url	string	The target to call. A public http or https URL on port 80 or 443.
delay_seconds	integer	Seconds to wait before firing, counted from the moment of the POST.
fire_at	integer	Unix timestamp of the delivery, used instead of `delay_seconds`.
payload	object	The JSON body handed to your target when the request goes out.

Both routes land in the same window. The fire time must sit between 5 seconds and 24 hours from now, and anything outside that is refused at once.

The resolution is one minute, not one second. Delivery runs once a minute, so a job fires at the next whole minute after it falls due, not at the exact second requested. Measured on 2026-08-21: a job due in 5 seconds was delivered 38 seconds later. Schedule in minutes and treat anything finer as noise.

curl -X POST https://aisenseapi.com/services/v1/webhook_schedule \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com/hook", "delay_seconds": 2}'

{"error":"fire_at must be between 5 seconds and 24 hours from now."}

A delay_seconds of 90000 draws the identical error, because it reaches past the 24-hour ceiling.

Check the result

curl https://aisenseapi.com/services/v1/webhook_schedule/e12681a8-f24f-4f24-9e34-7bbb0a9f9a77

Before the moment arrives, the job simply reports itself as waiting.

{
  "ok": true,
  "schedule_id": "e12681a8-f24f-4f24-9e34-7bbb0a9f9a77",
  "status": "scheduled",
  "url": "https://example.com/hook",
  "created_at_timestamp": 1787180038,
  "created_at_datetime": "2026-08-19T22:53:58+00:00",
  "fire_at_timestamp": 1787180048,
  "fire_at_datetime": "2026-08-19T22:54:08+00:00",
  "attempts": 0
}

An unknown or expired identifier answers with HTTP 404 and a short error object.

{"error":"Schedule id unknown"}

What the status field goes through

A job starts at scheduled. It ends at either fired or failed. Nothing else appears in that field.

Fired means a delivery was attempted. It does not mean your target was happy. The answer your server gave is recorded separately in http_status, so a target that replies 500 is still a fired job.

The real call below proves the distinction. The example target does not accept POST, so it answered 405, and the job is recorded as fired all the same.

{
  "status": "fired",
  "attempts": 1,
  "http_status": 405,
  "response_excerpt": "<!doctype html><html lang=\"en\"><head><title>Example Domain</title>...",
  "fired_at_timestamp": 1787180101,
  "fired_at_datetime": "2026-08-19T22:55:01+00:00"
}

Read attempts beside the status. A transport failure, where no HTTP answer comes back at all, is retried once. If the second try also gets nowhere, the job becomes failed. Results stay readable for 24 hours after the final attempt.

How the free webhook schedule API endpoint delivers

You post the job
The target and the payload are stored, and a schedule_id comes back immediately. Your own process is free to exit.
The clock runs on our side
Nothing is held open. No connection, no polling loop and no timer of yours has to survive the wait.
The request goes out
At the fire time we send the payload to your URL and record what came back, including the HTTP status and an excerpt of the response body.
You read the outcome
A GET on result_url tells you which of the two end states the job reached, and how many attempts it took.

This is the timer an autonomous process does not otherwise have. A script that wants something to happen in twenty minutes usually has to stay alive for twenty minutes. Here it does not.

What it will not call

Private, loopback, link-local and reserved addresses are refused. The check runs at creation and again at delivery time, with the connection pinned to the address that was checked, so a hostname cannot pass validation and then quietly repoint at an internal service.

curl -X POST https://aisenseapi.com/services/v1/webhook_schedule \
  -H "Content-Type: application/json" \
  -d '{"url": "http://127.0.0.1/hook", "delay_seconds": 60}'

{"error":"Target address is private or reserved."}

Redirects are never followed, and credentials in the URL are rejected outright. These guards are what keep a public scheduler from becoming a tool for reaching inside private networks.

Common uses

Most callers reach the free webhook schedule API endpoint from a pipeline rather than a browser. Four patterns come up again and again.

Agent wait states

Let an autonomous process pause and be woken by a callback instead of holding a connection.

Timeouts and reminders

Schedule a follow-up that fires unless something cancels it first.

Retry after a delay

Re-trigger a step a few minutes after a transient failure.

Deferred notifications

Send a message at a specific later time without running a scheduler yourself.

Privacy and limits

The payload is stored until delivery and for 24 hours after. Do not schedule secrets you would not want held for a day. The horizon is capped at 24 hours because this is a 24-hour service throughout.

The base URL is https://aisenseapi.com/services/v1. No key and no account are required. Every service on the free public REST APIs hub shares one limit of 5000 requests per IP per 24 hours, and a schedule POST and a result GET both count against that same budget.

Point the job at a target you control. The free webhook schedule API endpoint has no way to tell a wanted callback from an unwanted one, so treat the delivery as traffic you are responsible for.