Docs
The short version — how cronhook works and what you get per plan.
Create a job
Sign in first — all API calls except /api/health and /api/webhooks/* require an authenticated session. We use NextAuth session cookies; grab the next-auth.session-token from your browser (Dev Tools → Application → Cookies) to try from curl.
POST /api/jobs
Content-Type: application/json
Cookie: next-auth.session-token=<token>
{
"name": "Nightly sync",
"url": "https://api.example.com/sync",
"method": "POST",
"cron": "0 3 * * *",
"headers": { "authorization": "bearer $TOKEN" },
"body": "{\"batch\":true}"
}Cron expressions
Five-field standard cron (minute, hour, day-of-month, month, day-of-week). Minimum granularity is one minute.
*/5 * * * * every 5 minutes 0 * * * * top of every hour 0 3 * * * daily at 03:00 0 9 * * 1-5 weekdays at 09:00 0 0 1 * * first of the month
What happens when a job fires
- Scheduler checks every 30s for jobs due in the next minute.
- Due jobs are enqueued with a deterministic BullMQ id (
<jobId>-<timestamp>) so duplicates are impossible. - Worker makes the HTTP call with a 30s timeout.
- On 2xx: job logged as success.
- On non-2xx / timeout: BullMQ retries with 30s → 60s → 120s exponential backoff. Each attempt is its own audit row.
Quotas
Executions reset at the first of each calendar month (UTC). Retries do not count against your quota — only the first attempt per scheduled fire is billable. Over-quota jobs get a quota exceeded audit row but no outbound HTTP is made.
Endpoints
API access is in active build — email [email protected] for early access.
GET /api/jobs— list your jobsPOST /api/jobs— create a jobGET /api/jobs/:id— job detail (last 20 executions)PATCH /api/jobs/:id— update;enabledflips pause/resumeDELETE /api/jobs/:id— deleteGET /api/health— unauthenticated liveness probe
Questions, bug reports, or early API access? Email [email protected].