The Dataset API
A saved query can be exposed as a read-only API resource, so another system reads the result directly rather than being sent a spreadsheet.
Where to find it
Architect Panel → Data:
- Query Builder — the saved query and its key
Architect Panel → Integration & Connections:
- API Server — where the API and its exposure are configured
- API Clients — who may call it
- OpenAPI Specification — the generated description, including dataset paths
How it is addressed
A dataset is requested through the API using its saved-query key. The paths for exposed datasets are generated into the OpenAPI specification automatically, so a consumer discovers them the same way they discover everything else — and can generate a client rather than hand-rolling calls.
Why this beats sending files
The usual arrangement is a scheduled export emailed to a partner, who imports it. That has three problems: it is always slightly stale, it breaks silently when nobody notices the email stopped, and every copy is a copy of personal data sitting somewhere you do not control.
A dataset endpoint is read live, under a credential you can revoke, with no copy left behind.
Read-only, deliberately
A dataset is a query result. There is nothing to write to, which makes it a safe thing to expose — the worst case is disclosure, not corruption. That is a meaningfully smaller risk surface than exposing the underlying datastores for reading and writing.
Design the query for the consumer
Expose a query shaped for what the consumer needs, not your internal view. Include the fields they require and nothing else — internal notes, staff names and free-text fields written for colleagues do not belong on an interface somebody else reads.
This is easier than restricting a datastore, because you control the shape completely: the query is the contract.
It is a contract
Once a consumer builds against a dataset, its columns are a contract. Adding a column is safe; renaming or removing one breaks them, usually silently and usually in production.
If you must change the shape, publish a second dataset under a new key and retire the first with notice.
Worked example
A council exposes "open planning applications" as a dataset for its public-facing map. The query returns reference, address, description, status and dates — and deliberately not the case officer's name or internal notes. The map reads it live, so the public site is never stale, and no extract of planning data sits on a third-party server.
Recommendations
- Shape the query for the consumer, not for yourself.
- One dataset per consumer purpose, with its own key.
- Never rename or remove a column without publishing a new key.
- Prefer a dataset to a scheduled file whenever the consumer can call an API.