Chain tasks together
Most real jobs aren't one task, they're four or five tasks that depend on each other's output. The Task Chaining API lets you define that sequence once and fire it with a single request, tracked under one task_id from start to finish.
Why chains exist
A voicemail becomes a support ticket only after it's transcribed, summarised, translated into the agent's language and pushed to a helpdesk. Wiring that by hand means four separate API calls, four separate task_ids to poll, and custom code to pass the output of step one into step two, plus error handling for each hop of that relay. POST /flow/chain replaces all of that with a single ordered list of steps, where each step's result automatically becomes the next step's input, so the dependency lives in the request body instead of in your own service code.
What happens under the hood
You submit an array of task types in order, plus the parameters each one needs, and the chain runs them sequentially on our global edge. If step two depends on a field produced by step one, you reference it directly in the chain definition instead of writing a router or a queue consumer yourself. The whole chain is billed and tracked as one async job, which means one place to look when something needs auditing, not a scattered trail of independent calls that happened to run close together in time.
What you get back
You receive one task_id immediately, and the chain executes in the background exactly like any other KIT task. The final result — and, if you ask for it, the output of every intermediate step — arrives through a signed webhook, or sits behind a signed link valid for 24 hours if you'd rather poll. That intermediate visibility matters in practice: if a translation step reads oddly, you can inspect the transcript that fed it without re-running the whole chain.
Failure handling, honestly
If a step fails, the chain retries that step up to three times before returning a clear error naming exactly which step broke and why. You are never charged for a failed task, so a chain that dies on step three doesn't quietly bill you for steps one through three as if they succeeded — you pay only for the work that actually completed, and the error tells you precisely where to resume or what input to fix.
Where it fits
Chaining is the backbone of pipelines you'd otherwise build with a workflow engine: content localisation, document ingestion, media processing, anywhere a handful of well-defined steps always run in the same order. Because it's a normal async KIT task, you can also nest a chain as one step inside a larger scheduled or conditional flow, so a nightly cron can trigger a chain, or a conditional branch can decide whether a chain runs at all.
What you can do with it
Multilingual support inbox
Chain transcription, summarisation and translation on every inbound voice message so agents see a short English summary regardless of the caller's language.
Podcast to blog post
Feed a raw audio file in and get a translated, publish-ready article out, without stitching together three separate services yourself.
Compliance document intake
Chain OCR, translation and summarisation so legal teams receive a reviewable digest of foreign-language contracts within one tracked job.
Marketing localisation
Summarise a long-form English release, translate the summary into five markets, and publish each variant, all under a single task_id for auditing.
FAQ
How do I define the order of steps in a chain?
You send an ordered array to POST /flow/chain, and each entry can reference fields from any earlier step's output as its own input.
Is the Task Chaining API free to try?
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.
Do I get the output of every step, or just the last one?
By default you get the final result, but you can request intermediate outputs from every step in the chain in the same response.
What happens if one step in the middle fails?
That step retries up to three times automatically; if it still fails, the chain stops and returns a specific error identifying the failed step, with no charge for the failure.
How do I get the result — webhook or polling?
Either: register a signed webhook to be notified the moment the chain completes, or fetch the result from a signed link that stays valid for 24 hours.
Can a chain call any KIT task type?
Yes, a chain step can reference any task available on the platform, so you can mix transcription, translation, OCR, summarisation and other task families freely.
Is there a limit to how many steps a chain can have?
Chains are designed for typical pipelines of a handful of steps; extremely long sequences are better split into nested chains or a scheduled flow for clarity and easier debugging.
How is chaining different from calling tasks one by one myself?
Calling tasks yourself means managing multiple task_ids, writing the code that passes outputs to inputs, and polling each one; chaining does all of that server-side under one task_id.
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/chain \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"input":"…"}'const res = await fetch("https://api.kit.forhosting.com/flow/chain", {
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/chain",
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/chain", 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/chain", 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.chain",
"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. |