Queries

Show API code examples on this page as

Queries are the primary way of getting data out of Triggerware using the connectors you have installed.

We recommend describing what data you need in plain English. Triggerware uses an LLM to construct a query, fetching and correlating data from the list of your installed connectors:

POST /query

curl -X POST https://api.triggerware.com/query \
  -H "Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{...}'

Responses always look like this:

{
  "sql": "select title, year from pubmed_articles where query = 'CRISPR' limit 2",
  "signature": ["title", "year"],
  "rows": [
    ["CRISPR-Cas9 for medical genetic screens", 2023],
    ["Base editing with CRISPR", 2022]
  ]
}

Writing SQL by hand

You can skip the English-to-SQL step and submit SQL directly — pass "language": "sql" instead of the default "english". You’ll need to know your connectors’ signatures, which you can view in the console.

Triggerware speaks a subset of standard SQL. Here are some differences worth noting:

Required columns must be constrained in WHERE. Each connector exposes one or more virtual tables, and some columns on those tables are marked required in the connector’s schema. These are the inputs the connector needs to fetch data — for an X (Twitter) connector, that’s the username; for a PubMed connector, that’s the query string. Every required column must appear in a WHERE clause with an equality predicate, or Triggerware can’t build a plan and will reject the query. There is no SELECT * FROM table — the connector doesn’t know what to fetch.
Temporal literals need an explicit type marker. Bare strings like '2024-01-01' are just strings; they won’t compare against date columns. Use the typed forms:
```
WHERE t.created_at >= TIMESTAMP '2024-01-01 00:00:00'
WHERE t.pub_date = DATE '2024-01-01'
WHERE t.duration > INTERVAL 5 MINUTE
```
There is no Boolean type; use 1 or 0 instead.
Result sets never contain duplicate rows, so SELECT DISTINCT is redundant.
A few standard features aren’t supported, such as window functions (OVER (...)), DISTINCT inside aggregates (SUM(DISTINCT x)), and DDL/DML since Triggerware is currently read-only.

Saved Queries

If you want to name a query, persist it, and re-run it on demand, use the saved queries API. Saved queries store their latest results so you can fetch them back without re-executing.

Create a saved query — Triggerware runs it in the background. The response comes back immediately with status: "pending"; poll the get endpoint until status flips to "success" or "error":

POST /queries

curl -X POST https://api.triggerware.com/queries \
  -H "Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{...}'

List all your saved queries:

GET /queries

curl https://api.triggerware.com/queries \
  -H "Api-Key: YOUR_API_KEY"

Fetch one, including the latest rows, signature, and any error message:

GET /queries/{name}

curl https://api.triggerware.com/queries/<name> \
  -H "Api-Key: YOUR_API_KEY"

Edit the SQL of a saved query. By default this also re-runs it; pass "run": false to update without re-running:

PATCH /queries/{name}

curl -X PATCH https://api.triggerware.com/queries/<name> \
  -H "Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{...}'

Re-run a saved query without changing its SQL:

POST /queries/{name}/run

curl -X POST https://api.triggerware.com/queries/<name>/run \
  -H "Api-Key: YOUR_API_KEY"

Delete a saved query:

DELETE /queries/{name}

curl -X DELETE https://api.triggerware.com/queries/<name> \
  -H "Api-Key: YOUR_API_KEY"