Skip to content
OnchainQueries

Getting started

Quickstart

Point the CLI at an OnchainQueries service, run a query with a typed parameter, and get back checksum-verified Parquet. Five minutes, three commands.

Configure access

Create a query_sk_ API key in your dashboard, then log in. The query executable should be on your PATH.

shell
query login

The CLI prompts for the key without displaying it, validates it without submitting a query, and writes it to your user configuration directory under query/config.json — atomically, with permissions 0600. You do not configure an endpoint: the release binary already knows where the service lives.

For non-interactive setup, pipe the key over standard input, or skip the config file entirely and pass it in the environment:

shell
printf '%s\n' "$QUERY_TOKEN" | query login
VariableDefaultPurpose
QUERY_API_TOKENNoneAccount API key sent as the bearer token
QUERY_CONFIGOS user config directoryOverride the CLI config file path

QUERY_API_TOKEN takes precedence over a saved login.

Write your first query

Save this as trades.sql. Values you want to vary go in as {{name}} placeholders rather than being pasted into the SQL text.

trades.sql
SELECT  date_trunc('hour', ts) AS hour,  count_if(is_buy) AS buys,  count_if(NOT is_buy) AS sells,  sum(sol_amount) AS sol_volumeFROM pump_fun_solana.pump_fun_evt_trade_eventWHERE ts >= {{start_time}}GROUP BY hourORDER BY hour;

Run it

Submit the file and supply each parameter with its type. OnchainQueries validates the statement, resolves the table against its catalog, selects an engine, executes, and downloads the results.

shell
query sql \  --file trades.sql \  --param 'start_time:timestamp=2026-08-01 00:00:00' \  --output ./results

The CLI prints the query ID, the selected engine, the state and the attempt number while it waits. On completion it downloads every result part and writes the manifest last:

./results
results/├── part-00000.parquet└── manifest.json

Each part is downloaded to a .partial file, verified against its size and checksum, then atomically renamed. Rerunning against the same output directory reuses any part that already matches, and local files stay available after the server-side result expires.

Where to go next