Connect a project, then call the API
Create a project, configure its database, and load schema context. Add rules and business definitions in the workspace. Generate an API key with access to that project and keep it on your server.
Send POST /api/v1 with an x-api-key header, a prompt, and the project_id. The project supplies authoritative schema and policy context. Do not embed an API key in browser JavaScript or a public repository.
A minimal text to SQL request
Set TTSQL_API_KEY to your key and TTSQL_PROJECT_ID to the project's integer ID in your server environment.
bash
curl --fail-with-body https://ttsql.com/api/v1 \
-H "x-api-key: $TTSQL_API_KEY" \
-H "Content-Type: application/json" \
--data "{\"prompt\":\"Count all customers\",\"project_id\":${TTSQL_PROJECT_ID}}"
Handle generated SQL as a draft
A successful response contains status: success, query, executed: false, execution status, and request metadata. The API does not run the query, even if a legacy caller sends execute: true. Present the draft for review or pass it to a separate execution system with its own authorization and resource limits.
Treat an invalid key (401), missing project (404), validation failure (400), rate limit (429), and server failure as separate outcomes. Keep timeouts bounded, show actionable errors, and avoid retrying invalid requests unchanged. See the reference and language guides for working clients.
Build around a clear authorization boundary
An internal tool can show the question and query to an analyst. A reporting product can generate a draft for the customer's selected project. An agent can request SQL as one step in a larger workflow. In every case, keep the API key, project permissions, and any downstream database role on the server.
API access and request limits depend on the account's plan. Check current pricing and usage in the workspace before rolling out a high-volume integration.