Support replies
A queue of forty open tickets doesn't care that half of them are the same password-reset question phrased forty different ways. This endpoint reads the ticket and your help-centre content, then drafts a reply an agent can send with a glance instead of a rewrite.
Run it online
Run this on our servers with your account. Free tools run in your browser; this one bills your KIT balance per the price above.
The ticket queue nobody catches up on
Support teams rarely fall behind because the answers are hard — they fall behind because writing the same answer, phrased freshly enough not to feel copy-pasted, takes real minutes per ticket, and minutes multiply fast across a queue. A generic AI reply that ignores what your help centre actually says is often worse than no draft at all, because an agent then has to fact-check it before sending. text.support_reply is built around that gap: it drafts from your own documented answers, not from a guess.
How a draft gets built
POST /text/support-reply with the ticket text and a reference to your help-centre content, get a task_id back immediately, and receive the drafted reply by signed webhook or a signed link valid for 24 hours once the async task completes. The draft is grounded in the material you supply — policy pages, macros, past resolved tickets — so it reflects your actual refund window or your actual setup steps rather than a plausible-sounding invention.
Grounding is the whole point
Support replies are unusual among generated text because being wrong has a direct cost: a wrong refund policy or a wrong troubleshooting step erodes trust in a single reply. Grounded generation — anchoring a draft to specific source passages instead of open-ended generation — is the approach built for exactly that risk, and it is why this endpoint asks for your help-centre content up front rather than working from the ticket alone.
Where a human still decides
The output is a draft, not an auto-send: an agent reviews it, adjusts tone where a ticket is heated, and sends. Teams typically wire this endpoint into their existing helpdesk so a draft appears the moment a ticket is assigned, cutting first-response time without removing the person who actually knows when an exception is warranted. That review step also catches the rare case where a ticket blends two unrelated issues, something a template-based macro was never built to notice in the first place. Priced per request plus per ticket, the cost scales with volume the same way a queue does, and a task that fails is never billed.
What you can do with it
First-response drafting during peak hours
A support team feeds each incoming ticket through the endpoint so agents open a drafted, on-policy reply instead of a blank editor during the morning surge.
Consistent answers across a large agent roster
A company with rotating support staff uses grounded drafts so a refund or shipping answer stays consistent no matter which agent is on shift.
Multilingual support without a full team per language
A product with users across regions drafts replies grounded in the same help centre, then has a bilingual agent review before sending in the customer's language.
Triage for a documentation gap
When a draft comes back thin or uncertain, that signals the help centre itself is missing an answer worth writing down for next time.
FAQ
How does the support reply API generate an answer?
POST the ticket and your help-centre content to /text/support-reply, keep the task_id, and collect the drafted reply by webhook or a signed link valid for 24 hours.
Is the customer support reply API free?
No, there's no free tier or trial; it costs $0.003 per request plus $0.0135 per ticket, and a failed task is never charged.
Does it just make up an answer?
No, the draft is grounded in the help-centre content you supply, which is why providing accurate source material matters more than the wording of the ticket itself.
Can it send the reply automatically?
No, it returns a draft for a human agent to review and send; nothing goes to a customer without that review step.
Does it work for tickets in different languages?
It can draft from ticket text in various languages when your help-centre content covers the same ground, though a bilingual reviewer should confirm tone before sending.
Can I process a whole day's ticket backlog at once?
Yes, each ticket is submitted as its own async request, so a backlog is a batch of requests rather than a single oversized job.
Is this endpoint live yet?
Yes, it's live and accepting requests now.
Is my ticket and help-centre data kept afterward?
No, submitted data and results are deleted after the retention window and are never used for training.
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/text/support-reply \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"input":"…"}'const res = await fetch("https://api.kit.forhosting.com/text/support-reply", {
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/text/support-reply",
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/text/support-reply", 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/text/support-reply", 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": "text.support_reply",
"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.
Limits
max_tokens | 20000 |
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. |
422 | task_failed | The task failed after 3 retries. You are never charged for it. |