Support replies
Each ticket gets a reply drafted from your own help centre, so a refund question carries your real refund window and a setup question your real steps. The agent checks it with a glance instead of a rewrite. You pay per use, with no subscription.
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.
A queue of forty open tickets doesn't care that half of them are the same password-reset question phrased forty different ways.
Why support queues fall behind
Support teams rarely fall behind because the answers are hard. They fall behind because writing the same answer again, phrased freshly enough not to feel pasted, takes real minutes per ticket, and those minutes multiply across a queue. A morning backlog where half the tickets are the same password-reset question asked in different words is the typical case. A generic generated reply does not solve it: if the draft ignores what your help centre actually says, the agent has to fact-check every line before sending, which is often worse than starting from nothing.
Drafts grounded in what your company really says
Here the draft is anchored to the material you supply, such as policy pages, saved replies and past resolved tickets, so it reflects your actual policies rather than a plausible-sounding invention. That matters because a wrong refund policy or a wrong troubleshooting step costs trust in a single message. Teams with rotating staff use it to keep the same answer no matter who is on shift. Products with customers in several regions draft from one help centre and have a bilingual agent review before sending. And when a draft comes back thin or uncertain, it signals a gap: the help centre is missing an answer worth writing down.
What you can do with it
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
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 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.
Related tools
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, by email and from Telegram — and soon from our app too.
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 '{"text":"El informe trimestral cerró con 1,2 M€ de ingresos."}'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({
"text": "El informe trimestral cerró con 1,2 M€ de ingresos."
})
});
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={
"text": "El informe trimestral cerró con 1,2 M€ de ingresos."
},
)
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" => '{"text":"El informe trimestral cerró con 1,2 M€ de ingresos."}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"El informe trimestral cerró con 1,2 M€ de ingresos."}`)
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
{
"text": "El informe trimestral cerró con 1,2 M€ de ingresos."
}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. |
Technical notes
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.
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
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. 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.
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.
Integration use cases
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.
Technical questions
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.
Is this endpoint live yet?
Yes, it's live and accepting requests now.