Turn a question into SQL
Ask which customers had two or more refunds this quarter and get a runnable query built only from the tables and columns you supply, plus a short note on what it does. 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.
The gap between 'how many orders shipped late last month' and a correct JOIN across three tables is where most non-engineers give up and file a ticket instead.
Why the query starts from your own tables
Most people who need data know exactly what they want to ask: how many orders shipped late last month, or which customers asked for two or more refunds this quarter. What stops them is the gap between that question and a correct join across three tables. Generic tools that never see your real database tend to guess table names that do not exist. This one works from the structure you send: table names, columns, types and, if you have them, the foreign keys between tables. The query it writes uses only those names. You can also choose PostgreSQL, MySQL or SQLite, because they disagree on date functions, joining text and how LIMIT and OFFSET behave.
Review the query before it touches real data
Treat a generated query the way you would treat one written by a new hire. For anything people depend on, run it against a read-only connection or a replica, never straight against production. Each answer comes with a plain-language note explaining what the query does and what it had to assume, for example which date column it used when your tables had two candidates. That note lets you check the logic of a join or a filter before you trust the numbers. Support leads, analysts and product managers get a usable query without waiting for an engineer, and engineers get a readable draft instead of a vague request.
A note on trust
Generated SQL should always run against a read-only connection or replica for anything user-facing, the same discipline you'd apply to a query written by a new hire. The task explains its query rather than hiding the logic, so you can review a JOIN or a WHERE clause before it touches production data.
What you can do with it
Self-service analytics for support
A support lead asks 'which customers had two or more refunds this quarter' and gets a runnable query without waiting on an engineer's availability.
Dashboard query box
An internal tool lets product managers type questions in plain language and shows them the generated SQL alongside the results table for transparency.
FAQ
Which SQL dialects are supported?
PostgreSQL, MySQL and SQLite are supported; specify the dialect since date handling, string functions and pagination syntax differ between them.
Is there a free way to try it?
There's no free tier — free tiers get abused and slow everyone down. No subscription, no tokens, no invented credits, and a failed task is never charged.
Is the SQL safe to run directly against production?
Treat generated SQL like a query from a new hire: review it, and for anything user-facing run it against a read-only replica rather than a live write connection.
What do I need to give it besides my question?
Your table structure: the table names, their columns and types, and optionally the foreign keys that link them. The query only uses what you supply, so it does not invent tables that are not in your database.
How do I know the query does what I asked?
Every query comes with a short plain-language note that explains what it does and any assumption it made, such as which date column it picked when two could fit. Read it before you run the query.
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/dev/text-to-sql \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"El informe trimestral cerró con 1,2 M€ de ingresos.","schema":{"users":["id","email","created_at"]}}'const res = await fetch("https://api.kit.forhosting.com/dev/text-to-sql", {
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.",
"schema": {
"users": [
"id",
"email",
"created_at"
]
}
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/text-to-sql",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "El informe trimestral cerró con 1,2 M€ de ingresos.",
"schema": {
"users": [
"id",
"email",
"created_at"
]
}
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/text-to-sql", 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.","schema":{"users":["id","email","created_at"]}}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"El informe trimestral cerró con 1,2 M€ de ingresos.","schema":{"users":["id","email","created_at"]}}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/text-to-sql", 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.",
"schema": {
"users": [
"id",
"email",
"created_at"
]
}
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.text_to_sql",
"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. |
422 | task_failed | The task failed after 3 retries. You are never charged for it. |
Technical notes
This endpoint takes your schema and a question in plain English or Spanish and returns a query written against the tables and columns that actually exist.
The problem this closes
Analysts, support leads and product managers usually know exactly what they want to ask a database and have no interest in learning the difference between a LEFT JOIN and an INNER JOIN to get it. Handing every ad-hoc question to an engineer is slow for both sides, and generic text-to-SQL tools that don't see your real schema tend to invent table names that don't exist. This endpoint is built around the schema you send it, not a guess at what a typical e-commerce database looks like.
What you provide
You can also name the SQL dialect you need, since PostgreSQL, MySQL and SQLite disagree on things like date functions, string concatenation and how LIMIT and OFFSET behave, and a query that's syntactically fine in one will error in another. You send your schema (table names, columns, types, and optionally foreign keys) plus the question in natural language.
What comes back
The response is a query written strictly against the columns and tables you supplied, plus a short plain-language note explaining what the query does and any assumption it had to make, such as which date column it used when your schema had two candidates. If the question can't be answered from the schema as given, for instance it references a metric no table tracks, the task says so instead of returning a query that runs but returns the wrong thing silently.
Where this fits
The common integration is a query box inside an internal dashboard or a Slack bot: someone types a question, the request goes out with the current schema attached, and the returned SQL either runs directly against a read replica or gets shown to the person for a quick sanity check before running. Because it's asynchronous with webhook delivery, it also fits batch scenarios where dozens of stored report questions are regenerated overnight after a schema migration.
Integration use cases
Report regeneration after a schema change
A team migrates a database and resubmits its library of saved report questions so the SQL is rewritten against the new column names automatically.
Onboarding new analysts
New hires unfamiliar with a sprawling internal schema use it to get a working starting query, then refine it themselves as they learn the tables.
Technical questions
Does it need my real schema or does it guess table names?
It needs your actual schema; you send table and column names and the API writes against exactly those, so it never invents tables that don't exist.
What does it cost?
$0.003 per request plus $0.0135 per query, and you're only charged for queries that complete successfully.
What happens if my question can't be answered from the schema?
The task reports that the question doesn't map to available tables or columns instead of returning a query that runs but produces a misleading result.
Can I use it for report automation, not just one-off questions?
Yes, it's async with webhook delivery, so batch regeneration of many saved questions, for example after a migration, fits naturally.
Is my schema or data stored after the request?
No. Submitted schema and questions are deleted after the retention period and are never used to train models.