How to Find Which Retool Apps Use a Resource

If you've ever needed to deprecate an API endpoint or swap out a database connection, you already know the pain: Retool gives you no obvious way to see which apps use a specific resource. You're left clicking through every app, opening every query, and hoping you don't miss one. This guide covers every available method — from the modern built-in UI to a raw SQL workaround for self-hosted users — so you can audit resource usage with confidence before making any changes.

Why This Matters Before You Delete a Resource

Deleting or modifying a resource in Retool without knowing its dependents is a fast way to break production apps. A resource might back a dozen queries across five different internal tools — and none of that is visible from the Resources settings page by default. This is a well-documented gap: the Retool community thread on this exact issue has been active since 2022, with engineers asking for a bulk export or API endpoint just to run a grep.

The Easiest Fix: Built-In Resource Usage (Retool 2.116.0+)

If your Retool instance is on version 2.116.0 or newer, this problem is largely solved out of the box. Retool added a native feature that shows a list of apps using any particular resource directly in the UI. You'll also get a warning if you try to delete a resource that is still in use.

If you're on an eligible version but don't see this feature yet, here's how to enable it:

• Navigate to your Retool Settings page.
• Click the Beta tab.
• Enable the resource usage visibility toggle.

Once enabled, open any resource from your Resources page and you'll see a list of every app that references it. You can also sort your resources by usage to quickly spot which ones are most widely depended on — useful for change-impact assessments before any migration.

For Self-Hosted Retool: Query the Database Directly

If you're running a self-hosted Retool instance on an older version (prior to 2.116.0), you can query the underlying Postgres database to find resource dependencies. This is the most reliable workaround available before the native feature shipped.

The query below identifies the most recent save of each app and checks whether it references a given resource by name. Save it to your Query Library so your team can reuse it with different variable inputs:

with most_recent_saves as (
select * from (
select ps.*, row_number() over (partition by "pageId" order by "updatedAt" desc) as rs
from page_saves ps
) ps_ranks
where ps_ranks.rs = 1
),
resource as (
select r.name as uuid from resources r
left join resource_folders rf on r."resourceFolderId" = rf.id
where r."displayName" = {{resource_display_name}}
and rf.name = {{resource_folder_name}}
),
pages_with_resource as (
select * from most_recent_saves
where cast(data as text) ilike (select concat('%', resource.uuid, '%') from resource)
)
select concat(f.name, '/', p.name) as app_name
from pages_with_resource pwr
left join pages p on pwr."pageId" = p.id
left join folders f on p."folderId" = f.id

The query takes two inputs: {{resource_display_name}} (the exact display name of the resource, whitespace-sensitive) and {{resource_folder_name}} (the folder the resource lives in — use root if it's not in a folder). The output is a list of folder/app_name paths for every app that references the resource in its most recent save.

Important: This query is read-only and safe to run. Do not write to or modify the Retool storage database directly — many values are interdependent and manual changes can corrupt your instance.

For Retool Cloud Users on Older Versions

If you're on Retool Cloud and below version 2.116.0, you don't have access to the internal database. Your only option at that point is to manually export each app as a JSON file from the Retool home page and search through the exported files for the resource name. Apps must be exported individually — there is no bulk export API available as of version 2.107.1. This is tedious, but it works: the exported JSON includes all query definitions and their associated resource references, so a simple text search will surface what you need.

Step-by-Step: Auditing Resource Usage Before a Change

• Check your Retool version. If you're on 2.116.0+, use the built-in UI. Enable it under Settings → Beta if needed.
• Self-hosted on an older version? Run the SQL query above against your Retool Postgres database with the exact resource display name and folder.
• Cloud on an older version? Export apps individually from the home page and grep the JSON for the resource name.
• Document your findings. Before making any changes, list every affected app so you can test each one after the migration.
• Update queries in bulk where possible. If multiple apps share a Query Library query tied to the resource, updating the library query propagates the change everywhere it's used.

The Bottom Line

Retool's native resource usage visibility is the right long-term answer, and it's available now for anyone on version 2.116.0 or later. If you're stuck on an older self-hosted version, the SQL query against the page_saves table is a solid, safe workaround that the Retool team itself recommends. Either way, you no longer have to click through every app and every query to figure out what breaks when an endpoint changes.