canonical: https://jentic.com/apis/datasette.local/datasette # Datasette API Datasette publishes a read-only HTTP interface for SQLite databases, letting any caller execute a SQL query and receive the results as JSON. This spec exposes the canonical query endpoint on the public datasette.io content database, which contains tooling, plugin, and project metadata maintained by the Datasette project. The API is the same JSON interface the Datasette dashboard uses internally, so whatever you can see in the UI is reachable via SQL. ## For AI agents Run arbitrary read-only SQL queries against a hosted SQLite database and receive the result rows as JSON. ## Scope Does not handle SQL writes, schema migrations, or PRAGMA statements - use for read-only SELECT queries against the Datasette content database only. ## Capabilities - Execute a read-only SQLite SELECT query via GET /content.json - Return result rows as a JSON array shaped via the _shape parameter - Run joins and aggregations across the Datasette content database tables - Power AI agents that need ad-hoc structured queries against a small reference database - Drive lightweight reporting without standing up a separate analytics warehouse ## Use cases ### Ad-hoc SQL Reporting Analysts and tooling authors run ad-hoc SQL queries against the Datasette content database via GET /content.json to pull plugin lists, project metadata, and tooling references without scraping the Datasette site. Because the endpoint accepts arbitrary SELECT statements, callers can shape exactly the report they need in a single round-trip. Example prompt: Execute the SQL query 'SELECT name, description FROM plugins WHERE category = ''visualization'' LIMIT 20' against /content.json and return the JSON rows ### Plugin Discovery for Tooling Tooling that builds on Datasette (CLI helpers, generators, doc bots) queries the content database to discover available plugins, their descriptions, and version metadata. The single SQL endpoint is sufficient for read-only metadata browsing because the underlying SQLite schema is well-known and stable. Example prompt: Run 'SELECT name, repo_url FROM plugins ORDER BY stars DESC LIMIT 10' to fetch the most-starred Datasette plugins ### Lightweight Reference Lookups Documentation sites and chatbots that need to answer questions like 'what Datasette plugins exist for charting' run a focused SELECT against the content database rather than scraping HTML. The JSON-only response shape (_shape=array) keeps parsing trivial on the consumer side. Example prompt: Run a SELECT to find Datasette plugins tagged 'charts' and return name plus description as JSON for a chatbot answer ### AI Agent SQL Tool AI agents that already know SQL use Datasette through Jentic as a structured query tool against the published content database. The agent generates a SELECT, calls /content.json with sql and _shape=array, and feeds the JSON rows back into its reasoning loop. Because Datasette is read-only and SQLite refuses PRAGMA, the surface is safe to expose to autonomous agents. Example prompt: Generate and execute a SELECT against /content.json that returns the count of plugins per category, then summarise the top three ## Key endpoints | Method | Path | Description | | --- | --- | --- | | GET | `/content.json` | Execute a read-only SQL query and return JSON rows | ## Key resources - **content.json** — Canonical SQL-over-HTTP endpoint for the Datasette content database ## Why Jentic - **Setup:** Wiring Datasette by hand means learning its URL convention: the query goes on /content.json with sql and _shape parameters, and there is no key to manage since the endpoint is unauthenticated. Through Jentic you install once, import Datasette from the API Directory, and your agent calls the read-only query operation directly. - **Permission scoping:** Datasette's content endpoint carries the SQL in the request, not a resource id in the URL path, so scope the agent to the operations it needs, such as running a SELECT against /content.json. The spec exposes read-only querying only, so no write, migration, or PRAGMA path is reachable. - **Credential handling:** The Datasette content endpoint is unauthenticated, so there is no key to store. Jentic still routes the call through your own Jentic One instance at execution time so usage stays observable and consistent with the rest of the directory. - **Discovery method:** Agents search Jentic by intent such as 'run a SQL query against Datasette', and Jentic returns the GET /content.json operation with its sql and _shape parameters so the agent composes and executes the SELECT without learning the Datasette URL convention. ## Related APIs - **Supabase** — Supabase exposes a hosted Postgres database via REST and PostgREST; Datasette exposes a hosted SQLite via SQL-over-HTTP. - **Airtable** — Airtable offers a no-code structured database with REST endpoints; Datasette is SQL-first with a single query endpoint. - **Apify** — Apify scrapes data; Datasette is a way to publish small SQLite datasets as a queryable API. ## FAQ ### What authentication does the Datasette API use? The Datasette content endpoint described in this spec is unauthenticated and read-only - no API key is required. Through Jentic, the call is still proxied so usage is observable, but no credential is involved. ### Can I run arbitrary SQL queries against the Datasette API? Yes, but only read-only SELECT statements. The /content.json endpoint accepts any SQLite-compatible SQL via the sql query parameter and refuses PRAGMA statements, which keeps the surface safe for untrusted callers and AI agents. ### What are the rate limits for the Datasette API? Datasette is a community-hosted service; there is no formal rate limit in the spec, but heavy automated load on datasette.io is discouraged. For production workloads, host your own Datasette instance. ### How do I run a SQL query through Jentic? Search Jentic for 'run a SQL query against Datasette', load the GET /content.json operation, and execute it with the sql parameter set to your SELECT statement and _shape set to 'array'. Jentic returns the JSON rows directly. ### Does the Datasette API support write operations? No. /content.json is strictly read-only and PRAGMA is blocked. To write to a SQLite database via Datasette, host your own instance with the datasette-write plugin and a separate authenticated endpoint. ### What database does this Datasette endpoint query? It queries the public datasette.io content database, which contains Datasette project, plugin, and tooling metadata. The schema is browseable in the Datasette UI at datasette.io and the same tables are reachable via SQL through this endpoint. ### Can I limit what my agent is allowed to do with the Datasette API? Yes. Because you run Jentic One yourself, your own rules decide which operations your agent may call, so you can scope it to just the read-only GET /content.json query operation and nothing else. The Datasette API carries the SQL in the request rather than a resource id in the URL path, and it exposes read-only querying only, so no write, schema migration, or PRAGMA path is reachable through it. This means an agent you grant access to can run SELECT statements against the content database while remaining unable to modify any data.