Schedule a task
A task you run once is a request; a task you run every night at 2am is infrastructure. The Scheduled Task API lets you attach a cron expression to any KIT task so it fires automatically, without you standing up a cron server or a scheduler service just to keep it alive.
Why recurring jobs deserve their own primitive
Plenty of real work is periodic by nature: a nightly translation sync, an hourly transcription sweep of new recordings, a weekly document summary for a report. Running these manually, or wiring your own cron job that calls the API, means you now own an extra piece of infrastructure whose only purpose is to remember to make a request, and whose failure mode — a silently dead cron daemon — is easy to miss until someone notices stale data. POST /flow/schedule removes that piece entirely by making the schedule part of the task definition itself.
How scheduling works
You submit a standard cron expression alongside any task type and its parameters, and the platform takes over triggering it at each matching time. Each run executes independently on our global edge, exactly like a one-off request would, with its own outcome and its own delivery, so there's nothing special to learn beyond the cron syntax you already know from every other scheduler you've used.
What happens on every run
Every scheduled execution generates its own task_id, so a nightly job produces a distinct trackable record each night rather than one long-running process you have to interpret. Results from each run arrive the same way as any other task's: a signed webhook, or a signed link valid for 24 hours if you'd rather fetch it yourself, which means the same integration code you'd write for a one-off request works unchanged for a recurring one.
Reliability without surprise charges
If a scheduled run fails, it gets the same three retries as any other KIT task before returning a clear error for that specific occurrence, and a failed run is never charged. One bad run on Tuesday doesn't cancel or corrupt Wednesday's, since each execution is independent, so a temporary hiccup in one night's source data never puts the rest of the schedule at risk.
Where scheduling fits the bigger picture
Because a schedule can trigger any task type, including a chain, a fan-out or a batch, it's the piece that turns a one-time pipeline into a standing process: a nightly batch translation of new catalogue entries, a weekly scheduled chain that summarises and emails a report, an hourly conditional check on incoming files that routes anything unusual to review. It's the last piece that turns tasks you'd otherwise run by hand into something that simply keeps running.
What you can do with it
Nightly catalogue translation sync
Schedule a batch translation task to run every night at a fixed hour, keeping a multilingual storefront in sync with new or changed product entries automatically.
Hourly transcription sweep
Trigger a transcription task every hour to process newly uploaded recordings without a person or a separate script needing to kick it off.
Weekly report chain
Run a scheduled chain every Monday morning that summarises the week's documents and delivers the result by webhook to a reporting system.
Recurring content quality check
Schedule a conditional task daily to flag content that falls below a quality threshold, routing it to review automatically as it's found.
FAQ
What format does the schedule use?
A standard cron expression, submitted alongside the task type and parameters to POST /flow/schedule.
Is the Scheduled Task API free to set up?
There's no free tier — free tiers get abused and slow everyone down. Access runs on a prepaid ForHosting KIT balance: top up from $10.00 (it never expires) and each request is charged at its published price, so a call with no balance returns HTTP 402. No subscription, no tokens, no invented credits, and a failed task is never charged.
Does each scheduled run get its own result?
Yes, every execution produces its own task_id and its own result, delivered independently, so you can track and audit each run separately.
Can I schedule any task, including chains and batches?
Yes, a schedule can trigger any KIT task type, including a chain, a parallel fan-out, a conditional flow, or a batch job.
What happens if a scheduled run fails?
It gets up to three automatic retries like any other task, then returns a specific error for that occurrence, with no charge for the failed run, and later scheduled runs are unaffected.
How do I get notified when a scheduled run finishes?
Register a signed webhook to be notified as each run completes, or retrieve the result from a signed link that stays valid for 24 hours.
Can I change or cancel a schedule after creating it?
Yes, a schedule can be updated or removed once it's no longer needed, stopping future runs without affecting ones that already completed.
Is scheduling the same as running a task in a loop myself?
No, running your own loop or cron job means maintaining that infrastructure yourself; scheduling here means the recurrence lives inside the task definition, with no server of your own required.
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, and soon from our app, email and Telegram.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/flow/schedule \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"input":"…"}'const res = await fetch("https://api.kit.forhosting.com/flow/schedule", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"input": "…"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/flow/schedule",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"input": "…"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/flow/schedule", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"input":"…"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"input":"…"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/flow/schedule", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"input": "…"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "flow.schedule",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |