setTimeout() won't survive the deploy.
Dispatch is a webhook scheduler with one job: you POST a URL and a time, and your endpoint gets called at that time. No cron to babysit, no queue to operate, no in-memory timer that dies on restart.
01/how it works
The whole integration.
Three steps, two of which you only do once. There is no step four.
- 01
Create a project, copy the key
Every project gets its own API key. One for staging, one for production — revoke either without touching the other.
key: dsp_live_4f8a2c9b51de - 02
POST the job
A URL, a timestamp, and an optional payload. That is the entire schema — if you can send an HTTP request, you have finished integrating.
{ "url": "…", "run_at": "2026-06-12T09:30:00Z" } - 03
Dispatch fires the webhook
At the scheduled second, your endpoint gets the request. If it fails, Dispatch retries with backoff and logs every attempt along the way.
09:30:00.000 → POST your-endpoint 200 OK · 142ms - →
That's the whole loop.
Create an account, grab a key, and your first webhook can be on the schedule in the next five minutes.
02/features
Everything it does.
Six things, on purpose. Scheduling infrastructure should be boring to integrate and boring to operate.
On time, to the second
Jobs fire at the timestamp you set. No polling loop between you and your deadline, no cron-resolution rounding, no drift.
Retries with backoff
A 500 or a timeout doesn't end the story. Failed deliveries retry on an exponential schedule until they land or run out of attempts.
Every attempt, logged
Status code, latency, and response body for every attempt — not just the last one. When an endpoint misbehaves, you can see exactly how.
Projects, not piles
Separate projects with separate API keys. Staging can't fire production's webhooks, and rotating one key never breaks the other.
No SDK
It's an HTTP API. curl works, fetch works, and your language already ships a client for it. Nothing to install, nothing to keep upgraded.
Yours to run
The whole service is open source under MIT. If scheduling has to live inside your infrastructure, run it there — same code, your box.
03/open source
Read the source before you trust it.
You should know what's holding your schedule before you hand it your webhooks.
Dispatch is MIT-licensed — the same code that runs the hosted service, not a gutted community edition. Clone it, audit it, and if your scheduling has to stay inside your own infrastructure, run it there. Everything on this page works the same way, pointed at your own box.
And if one more hosted dependency is exactly what your stack doesn't need — fair. That instinct is why the repo is public in the first place.