For the complete documentation index, see llms.txt. This page is also available as Markdown.

Workspace Data Queries

Register, manage, and invoke parameterized SQL queries against workspace custom tables.

Workspace data queries let you register parameterized SQL templates that the agent can invoke as tools during conversations. Unlike platform functions (which execute against an external data warehouse), data queries run directly against the custom tables you have provisioned in your workspace.

The agent runtime registers each query as a tool named wsq_<name>, so the agent can call it mid-conversation to fetch data from your workspace's custom tables.

Prerequisites

Your workspace must have at least one custom table provisioned (via POST /v1/{workspace_id}/tables) before you can deploy a data query. The per-workspace database role is created when the first table is provisioned.

Endpoints

Method
Path
Description

POST

/v1/{workspace_id}/data_queries

Create a data query (returns 201)

GET

/v1/{workspace_id}/data_queries

List all registered data queries

GET

/v1/{workspace_id}/data_queries/{query_id}

Get a single data query by ID

PATCH

/v1/{workspace_id}/data_queries/{query_id}

Update a data query

DELETE

/v1/{workspace_id}/data_queries/{query_id}

Delete a data query (returns 204)

POST

/v1/{workspace_id}/data_queries/{query_id}/invoke

Execute a data query with arguments

query_id (a UUID returned by create) is the immutable route handle. name is a mutable, workspace-unique label that registers the agent tool wsq_<name>.

Permissions

  • List / Get / Invoke: Requires Workspace.view permission.

  • Create / Update / Delete: Requires Workspace.update permission.

Create a Data Query

Create Workspace Data Query

post
Authorizations
AuthorizationstringRequired

API key issued via POST /v1/{workspace_id}/api-keys. Pass the returned api_key value as a Bearer token.

Path parameters
workspace_idstring · uuidRequired
Body

Create body — the authored shape of a new workspace data query.

The SQL template + parameters parity check + multi-statement / session-state-command refusal runs inside :meth:_validate_template so a bad payload surfaces as a Pydantic 422 with the standard wire shape — no try/except in the handler.

namestring · min: 1 · max: 128RequiredPattern: ^[a-z][a-z0-9_]*$
descriptionstring · min: 1 · max: 2048Required
sql_templatestring · min: 1 · max: 8192Required
timeout_msinteger · min: 100 · max: 30000OptionalDefault: 5000
Responses
201

Successful Response

application/json

Wire shape for the response of every read + create/update handler.

id (UUID) is the stable handle — every URL except list takes it. name is the workspace-visible label (UNIQUE per workspace) and is still what the LLM tool registry keys on (wsq_<name>), but it is not the route identifier.

input_schema is deliberately NOT exposed — it is fully derivable from parameters[]. UI consumers can build the JSON Schema view locally if they need it.

idstring · uuidRequired
namestringRequired
descriptionstringRequired
sql_templatestringRequired
timeout_msintegerRequired
last_invoked_atstring · date-time · nullableOptional
deployed_atstring · date-timeRequired
deployed_bystring · uuidRequired
post/v1/{workspace_id}/data_queries

Creates a new data query and returns it with a server-generated query_id (201 Created). Creating a query whose name already exists in the workspace returns 409 Conflict. To change an existing query, use PATCH on its query_id (see Update a Data Query).

Deploy-Time Validation

The platform validates the query before storing it:

  • SQL must parse as a single valid statement.

  • Multi-statement SQL is rejected.

  • Session-state commands are rejected.

  • Every :name placeholder in the SQL must have a matching entry in parameters, and every declared parameter must appear as a placeholder in the SQL.

  • Default values must match their declared type.

Example Request

Example Response

Update a Data Query

Update Workspace Data Query

patch
Authorizations
AuthorizationstringRequired

API key issued via POST /v1/{workspace_id}/api-keys. Pass the returned api_key value as a Bearer token.

Path parameters
workspace_idstring · uuidRequired
query_idstring · uuidRequired
Body

PATCH body — every field optional. Present ⇒ overwrite; absent ⇒ keep.

namestring · min: 1 · max: 128 · nullableOptionalPattern: ^[a-z][a-z0-9_]*$
descriptionstring · min: 1 · max: 2048 · nullableOptional
sql_templatestring · min: 1 · max: 8192 · nullableOptional
timeout_msinteger · min: 100 · max: 30000 · nullableOptional
Responses
200

Successful Response

application/json

Wire shape for the response of every read + create/update handler.

id (UUID) is the stable handle — every URL except list takes it. name is the workspace-visible label (UNIQUE per workspace) and is still what the LLM tool registry keys on (wsq_<name>), but it is not the route identifier.

input_schema is deliberately NOT exposed — it is fully derivable from parameters[]. UI consumers can build the JSON Schema view locally if they need it.

idstring · uuidRequired
namestringRequired
descriptionstringRequired
sql_templatestringRequired
timeout_msintegerRequired
last_invoked_atstring · date-time · nullableOptional
deployed_atstring · date-timeRequired
deployed_bystring · uuidRequired
patch/v1/{workspace_id}/data_queries/{query_id}

Partially updates an existing data query, addressed by its immutable query_id. Any subset of name, description, sql_template, parameters, and timeout_ms may be supplied; omitted fields are left unchanged. The name is mutable but must remain unique within the workspace. The same deploy-time validation applies to any updated SQL.

List Data Queries

List workspace data queries

get

List every registered query for a workspace. Sort via repeated sort_by query params; each entry is +field or -field (allowed field: deployed_at). Default: -deployed_at. Cursor opaque — round-trip continuation_token unchanged with the same sort_by. Requires Workspace.view permission.

Authorizations
AuthorizationstringRequired

API key issued via POST /v1/{workspace_id}/api-keys. Pass the returned api_key value as a Bearer token.

Path parameters
workspace_idstring · uuidRequired
Query parameters
sort_bystring[]Optional

Sort axes, applied left-to-right. +field ascending, -field descending. Defaults to [("deployed_at", -1)] (newest first).

Default: []
limitinteger · max: 200Optional

Maximum number of queries to return per page.

Default: 50
continuation_tokenanyOptional

Opaque continuation token from a prior response. Treat as a black box — the server decodes it.

Responses
200

Successful Response

application/json
has_morebooleanRequired
continuation_tokenanyOptional
get/v1/{workspace_id}/data_queries

Returns the workspace's registered data queries, ordered newest first. Results are paginated: when has_more is true, pass the returned continuation_token on the next request to fetch the following page.

Example Response

List items carry a parameter_count instead of the full parameters array. Fetch a single query by ID to get its parameter definitions.

Get a Data Query

Get Workspace Data Query

get
Authorizations
AuthorizationstringRequired

API key issued via POST /v1/{workspace_id}/api-keys. Pass the returned api_key value as a Bearer token.

Path parameters
workspace_idstring · uuidRequired
query_idstring · uuidRequired
Responses
200

Successful Response

application/json

Wire shape for the response of every read + create/update handler.

id (UUID) is the stable handle — every URL except list takes it. name is the workspace-visible label (UNIQUE per workspace) and is still what the LLM tool registry keys on (wsq_<name>), but it is not the route identifier.

input_schema is deliberately NOT exposed — it is fully derivable from parameters[]. UI consumers can build the JSON Schema view locally if they need it.

idstring · uuidRequired
namestringRequired
descriptionstringRequired
sql_templatestringRequired
timeout_msintegerRequired
last_invoked_atstring · date-time · nullableOptional
deployed_atstring · date-timeRequired
deployed_bystring · uuidRequired
get/v1/{workspace_id}/data_queries/{query_id}

Returns a single data query by its query_id.

Delete a Data Query

Delete Workspace Data Query

delete
Authorizations
AuthorizationstringRequired

API key issued via POST /v1/{workspace_id}/api-keys. Pass the returned api_key value as a Bearer token.

Path parameters
workspace_idstring · uuidRequired
query_idstring · uuidRequired
Responses
204

Successful Response

No content

delete/v1/{workspace_id}/data_queries/{query_id}

No content

Removes a registered data query, addressed by its query_id. Deleting a query cascades to its parameter rows automatically. Returns 204 No Content on success.

Invoke a Data Query

Invoke Workspace Data Query

post
Authorizations
AuthorizationstringRequired

API key issued via POST /v1/{workspace_id}/api-keys. Pass the returned api_key value as a Bearer token.

Path parameters
workspace_idstring · uuidRequired
query_idstring · uuidRequired
Body
Responses
200

Successful Response

application/json
duration_msnumberOptionalDefault: 0
row_countintegerOptionalDefault: 0
post/v1/{workspace_id}/data_queries/{query_id}/invoke

Executes a registered data query, addressed by its query_id, with the provided arguments.

Example Request

Example Response

Agent Tool Registration

When a conversation session starts, the platform loads all data queries for the workspace and registers each one as a tool available to the agent. The tool name follows the pattern wsq_<name> (for example, a query named active_patients_by_location becomes the tool wsq_active_patients_by_location). The agent sees the query's description and input schema, and can call it like any other tool.

Data query tools run under the workspace's own tenant-scoped database role, so they can only access tables the workspace has provisioned. This is distinct from platform function tools (prefixed fn_), which execute against an external data warehouse.

Last updated

Was this helpful?