How do I connect Dune to Lodol?

Authenticate Dune once from your workspace and every action and trigger it supports becomes available to drop into a workflow. There is no glue code to write or maintain.

All integrations

Dune

CryptocurrencyAnalyticsDatabases

Query blockchain data with Dune: run SQL against decoded data for 100+ chains, run the queries and dashboards your team has already built, and collect the results as rows or CSV. Search the catalogue of tables to find what to query, look up the decoded tables behind any smart contract address, upload your own data to join against onchain activity, and cache expensive queries as materialized views that refresh on a schedule.

Get Started Browse all integrations

30 actions

Actions

Steps your workflow can run in Dune.

Run a saved queryRun a query saved on Dune and get its rows back in one step. Running a query on Dune is normally three calls — start it, watch it, collect it — and this does all three: it submits the run, waits for it to finish, and returns the rows, the columns and what it cost in credits. Give it the query's address from dune.com, fill in any parameters the query takes, and narrow the result with the row, column, filter and ordering options so you only pay for the data you actually use. If the query is still running when the wait runs out, the step still succeeds and hands back the execution id for a later step to collect.

Run SQLWrite DuneSQL and get the answer back, without saving a query first. Dune's warehouse holds decoded data for 100+ chains — blocks, transactions, logs, token transfers, prices, NFT trades and the community's curated tables on top of them — and this runs a statement straight against it, waits for it, and returns the rows. Use Search tables first if you don't know what a table is called. Note that Dune charges for the compute a statement uses, so filter by time and select only the columns you need.

Start a query runStart a saved query running and return straight away with its execution id, without waiting for the rows. Use this for a query too slow to hold a workflow open on: start it here, and let a later step — or a scheduled run an hour from now — check it with Get execution status and collect it with Get execution results. For everything else, Run a saved query does all of it in one step.

Start a SQL runStart raw DuneSQL running and return straight away with its execution id, without waiting for the rows. The asynchronous half of Run SQL: use it for a statement too slow to hold a workflow open on, then collect the rows later with Get execution results.

Get execution statusCheck on a run that was started earlier: whether it is queued, running or finished, how many rows it produced, how long it took and how many credits it cost. This is the step to branch a workflow on — 'is finished' and 'succeeded' come back as plain true/false — and it costs no credits itself, so a scheduled workflow can poll it freely.

Get execution resultsCollect the rows a finished run produced, using the execution id from a step that started it. Results stay on Dune for 90 days, so the same execution can be read as many times as you like without running the query again. Use the row, skip, column, filter and ordering options to walk a large result a page at a time, or to pull only the part you need.

Get execution results as CSVThe same rows as Get execution results, but as CSV text rather than a list of objects — ready to write to a file, attach to an email or paste into a spreadsheet. The header row comes back split out separately as well, so a later step can see the column names without parsing the text.

Get a query's latest resultsRead the rows a saved query produced the last time it ran, without running it again. This is the cheap way to read Dune on a schedule: let the query refresh itself on Dune's own scheduler and just collect what is there, instead of paying for an execution every time. Works on any public query as well as your own. For a query with parameters, give the values you want and Dune finds the run that used them.

Get a query's latest results as CSVThe same rows as Get a query's latest results, but as CSV text — ready to write to a file, attach to an email or paste into a spreadsheet. The cheapest way to put a Dune dashboard's numbers somewhere else on a schedule.

Cancel an executionStop a run that is still going. Use it to cut a query loose that is taking longer than it is worth — a cancelled run stops consuming compute, though the credits already spent on it stay spent. Cancelling a run that has already finished is harmless: the step reports that it did not cancel and carries on.

Get a query's pipelineSee what a query actually depends on before you run it: every materialized view feeding it, and the order they run in. Use it to understand a query someone else built, to work out what a pipeline run will cost, or to find the views worth refreshing on their own schedule.

Run a query with its pipelineRun a query together with everything it is built on, as one unit: Dune refreshes each materialized view the query depends on, in dependency order, then runs the query itself. Use it when the query reads views that would otherwise be stale — it is the difference between a fresh number and yesterday's. Returns a pipeline execution id to follow with Get pipeline status.

Run a pipelineRun several queries and materialized view refreshes together, in an order you define. Each step names either a query or a view, and lists the steps it has to wait for; Dune runs everything that can run at once and holds back the rest. Use it to rebuild a set of related tables in the right order in a single call. For the common case — one query and whatever it depends on — Run a query with its pipeline works this out for you.

Get pipeline statusCheck on a pipeline run, step by step: which have finished, which failed and why, and the execution id each produced so its rows can be collected with Get execution results. Costs no credits, so a scheduled workflow can poll it freely.

Search tablesFind the table to query. Dune's catalogue holds tens of thousands of them — raw chain data, decoded contract events, curated cross-protocol models and everything the community has uploaded — and this searches it in plain language, narrowed by chain, by kind of table and by who maintains it. This is the step to put before Run SQL when you don't already know what something is called: turn on 'include each table's columns' and the next step has the column names to write against. Costs no credits.

Find tables for a contractGive a smart contract's address and get back every table Dune has decoded for it — one per event and one per function, each with its real column names. This is how an address becomes something you can write SQL against: paste it in, turn on 'include each table's columns', and the next step can query the contract's activity directly. Costs no credits.

List tablesWalk Dune's table catalogue a page at a time, optionally narrowed to one owner or to certain kinds of table. Use it to audit what your team has published, or to build a catalogue of your own; Search tables is the better step when you know what you are looking for. Costs no credits.

Get a table's columnsLook up one table by name and get its columns, their types and what each one holds. Put it before Run SQL to write a statement against the real column names instead of guessing at them. Costs no credits.

List uploaded tablesEverything this Dune account has uploaded: each table's name, columns, size and when it last changed. Use it to see what is taking up the plan's storage allowance (100MB on the Free plan), or to find the name of a table for a later step. Costs no credits.

Create a tableCreate an empty table on Dune with the columns and types you choose, ready for Insert rows to append to. Use this when data arrives repeatedly and has to build up — daily figures, a feed from another system — because rows can be added without replacing what is already there. For a one-off spreadsheet, Upload a CSV is simpler and works out the columns for you. Once the table exists you can join it to any Dune table in SQL.

Insert rowsAppend rows to a table that Create a table made. Rows go up as a list of objects — the same shape an earlier step produces — keyed by column name, so a workflow can carry data straight from another system into Dune without building a file. Rows are added to what is already there rather than replacing it, and either every row in the step lands or none does.

Upload a CSVTurn a CSV into a Dune table in one step, with the columns and their types worked out from the file. The quickest way to get your own data next to onchain data — a list of wallets to label, a price series, a team's targets — and query the two together in SQL. Uploading to a name that already exists replaces what was there, so a scheduled workflow can keep the table current; use Create a table and Insert rows instead when the data has to build up.

Clear a tableEmpty an uploaded table without deleting it: every row goes, the columns stay, and any query or dashboard reading the table keeps working. This is the first half of a full refresh — clear it, then insert the new data — and it frees the storage the old rows were using.

Delete a tableDelete an uploaded table and everything in it. This cannot be undone, and any query or dashboard reading the table will stop working. To empty a table but keep it queryable, use Clear a table instead.

List materialized viewsEvery materialized view this account owns: the query behind each one, how often it refreshes, when it next will, and how much storage it is using. Costs no credits.

Get a materialized viewOne materialized view in detail: the query it is built from, its refresh schedule and next refresh, its size, and the ids of its most recent refreshes — which can be read with Get execution results to see what it last produced. Costs no credits.

Create or update a materialized viewStore a query's results as a table that refreshes on a schedule. Anything reading the view gets an answer instantly and for far fewer credits than re-running the query, which is what makes an expensive query usable in a dashboard or on an hourly workflow. Pick how often it should refresh — Dune allows anything from every 15 minutes to weekly — and Dune keeps it current on its own. Naming a view that already exists updates it; either way a refresh starts straight away.

Refresh a materialized viewRebuild a materialized view now, instead of waiting for its schedule. Use it when something upstream has just changed and the next thing to read the view needs the new numbers. Returns the refresh's execution id, so a later step can wait for it with Get execution status.

Delete a materialized viewDelete a materialized view, its schedule and the stored table behind it. This cannot be undone, and any query reading the view will stop working. The query the view was built from is left alone.

Get credit usageHow many credits this Dune account has used and has left this billing period, plus how much of its storage allowance is taken. Credits are what a Dune workflow actually spends — the Free plan comes with 2,500 a month — so this is the check to put at the top of an expensive scheduled workflow, or on its own schedule to warn someone before the month runs out. Costs no credits itself.