Ask your document
Instead of skimming a 60-page contract for one buried fact, ask your question and get the answer taken from the document itself, not from general knowledge. It is not a summary and not a chat, just the grounded answer. 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.
get the answer from your own files
One question, one long document
Support teams, legal reviewers and researchers share a version of the same task: a long document exists, and somewhere in it is the answer to one question. Reading a 60-page contract to confirm a single clause or figure wastes a person's time, and searching inside the document only finds keywords, not answers. This tool reads the document you provide and returns the answer to the specific question you ask. It is not a summarizer and not a chatbot with a personality; it is a narrow tool for pulling a grounded answer out of your own text.
Why the answer has to stay inside the source
What separates document questions from open-ended writing is that the answer must come from the supplied text rather than from general knowledge. That constraint is what makes it useful for compliance and support work, where an answer invented from outside the document is worse than no answer. A legal team can ask the same twelve questions, such as termination notice, renewal terms or liability cap, of every vendor contract in a folder; a help desk can answer which plan a customer is on from an attached account document; an analyst can pull sample size, methodology and funding source from a batch of papers; an intake system can pre-fill a form field by field from an uploaded invoice.
The problem it solves
Support teams, legal reviewers and researchers all share a version of the same task: a long document exists, and somewhere in it is the answer to one question. Reading the whole thing to confirm a single clause or figure is a waste of a human's time, and generic search inside a document only finds keywords, not answers.
What you can do with it
Contract clause lookup
A legal ops team asks the same twelve questions — termination notice, renewal terms, liability cap — against every vendor contract in a folder.
Support ticket triage
A helpdesk tool answers 'what plan is this customer on' and similar questions directly from an attached account document instead of routing to a human.
Research paper extraction
An analyst pulls specific figures — sample size, methodology, funding source — from a batch of academic PDFs without reading each one in full.
Form pre-fill from source documents
An intake system answers a fixed set of questions from an uploaded ID or invoice to pre-fill a form field by field.
FAQ
What document formats and lengths are supported?
Plain text extracted from your document works best; longer documents simply take proportionally longer in the queue.
What happens if a task fails?
It retries automatically up to three times, and you are never charged for a task that ultimately fails.
Does the answer come from my document or from general knowledge?
Only from the text you provide. The tool is built to stay inside the source, because in compliance and support work an answer invented from outside the document is worse than no answer at all.
Can I ask several questions about the same document?
Yes, and each one is handled as its own task. A legal team, for example, can ask the same twelve questions, such as termination notice, renewal terms and liability cap, of every vendor contract.
How is this different from searching inside the document?
Search finds keywords and leaves the reading to you; this tool returns the answer itself. It is not a summary either, because it answers the specific thing you asked and nothing more.
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/qa \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"El informe trimestral cerró con 1,2 M€ de ingresos.","question":"¿Cuál fue el ingreso neto?"}'const res = await fetch("https://api.kit.forhosting.com/text/qa", {
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.",
"question": "¿Cuál fue el ingreso neto?"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/text/qa",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "El informe trimestral cerró con 1,2 M€ de ingresos.",
"question": "¿Cuál fue el ingreso neto?"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/text/qa", 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.","question":"¿Cuál fue el ingreso neto?"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"El informe trimestral cerró con 1,2 M€ de ingresos.","question":"¿Cuál fue el ingreso neto?"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/text/qa", 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.",
"question": "¿Cuál fue el ingreso neto?"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "text.qa",
"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
Instead of skimming a 60-page contract or a support ticket thread for one buried fact, the document Q&A API reads the document and answers the specific question you ask of it. It is not a summarizer and not a chatbot with a personality — it is a narrow tool for extracting a grounded answer from text you provide.
The problem it solves
This endpoint closes that gap by returning the answer itself, grounded in the text you send it.
How it works, in practice
Ask the same document multiple questions and each becomes its own tracked task — useful when a form or intake process needs several fields pulled from one source file. A call to POST /text/qa takes your document and your question, queues the task, and returns a task_id immediately. The answer comes back later through a signed webhook or a signed link valid for 24 hours, so your integration never has to hold a connection open waiting on a model to think.
Why answers stay grounded
The point of document Q&A, as distinct from open-ended text generation, is that the answer has to come from the supplied text rather than from general knowledge. That constraint is what makes it useful for compliance and support work, where an answer invented from outside the document is worse than no answer at all — this endpoint is built around staying inside the source.
Fitting it into a pipeline
Because every call returns a task_id and a webhook, document Q&A slots naturally after an OCR or text-extraction step: pull the text out of a scanned contract, pass it here with a checklist of questions, and let the results populate a review dashboard automatically. Nothing about the endpoint assumes a human is waiting at a keyboard for the reply.
What to expect
A short, well-defined document with a specific question returns a precise answer quickly; a sprawling document with a vague question takes longer and may return a more qualified answer, which reflects the material rather than a limitation you need to work around. There is no free tier, access requires prepaid balance, and a task that fails after three retries is never billed.
Technical questions
How does the document Q&A API work?
Send your document and question to POST /text/qa; the task is queued and the answer arrives later by signed webhook or a signed link valid for 24 hours.
Is the document Q&A API free to use?
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.
How much does each question cost?
$0.003 per request plus $0.0135 per question, and you are only billed for questions that are successfully answered.
Can I ask multiple questions about the same document?
Yes — send each question as its own request against the same source document; each gets its own task_id and result.
What if the answer isn't in the document?
The endpoint is designed to answer from the supplied text only, so an unanswerable question returns a clear indication rather than an invented answer.
How does this compare to just searching the document?
Keyword search finds where a term appears; this endpoint returns the actual answer to your question, synthesized from the relevant part of the text.