We're blocked from launching our app publicly because of this warning in General Access:
"Dynamic resource queries won't work in public apps. This app has 86 queries that select their resource dynamically. They will fail for users accessing the public app without signing in."
When testing our QA app as a public (signed-out) user, the first query in the flow (a login mutation) fails with:
{"status":403,"message":"Dynamic resource queries are not allowed in public apps.","statusCode":403,"error":"Forbidden"}
Our queries use dynamic resource mode (the Ζ button) with a JS function like:
What's strange: our original production app uses this exact same pattern and is currently live and publicly accessible WITHOUT this error. That app is sharing an older pinned release rather than the latest editor state.
Questions for the community / Retool team:
Is this restriction evaluated only at publish/release time (so older releases created before the restriction existed are grandfathered in), or enforced in real time regardless of release date?
Is "Dynamic resource queries are not allowed in public apps" a recently introduced policy? Does anyone know when it was rolled out?
We're on a non-Enterprise plan (no Source Control / Git). Besides manually disabling dynamic mode on every affected query, is there a supported way to bulk-update queries (e.g. via the Retool API)?
For apps needing to switch between environment-specific resources (dev/staging/production) in a public app without hitting this restriction β is configuring environment-specific credentials on a single resource (instead of dynamic resource mode) the recommended pattern?
Any pointers appreciated β happy to share more details if useful.
Hi WidleStudioLLP, thanks for checking! I don't think this reproduces our issue though.
You tested while signed into Retool as a builder β dynamic resource selection works fine in that case. Our issue only happens when accessing the app via the Public share link while fully signed out of Retool (our app's own "Sign in with Google" is a separate auth system, not Retool's).
Also, we're not doing dynamic SQL text β we're dynamically selecting the resource itself (via the Ζ button next to Resource ID), which Retool flags differently:
Attaching two screenshots: the General Access warning, and the actual 403 error we get when opening the public link signed out.
Could you try reproducing via an incognito window on the actual public share link (fully signed out)? That's where we consistently see the block, even though the same query works fine in the editor.
The issue is caused by dynamic resource selection, which Retool does not support in Public Apps. Since public users are not authenticated with Retool, queries using a dynamic Resource ID are blocked and return a 403 error. The recommended fix is to replace the dynamic resource with separate queries that use static resources (e.g., one for staging and one for production) and trigger the appropriate query based on the environment. Alternatively, use separate apps for each environment or avoid using Public Apps if dynamic resources are required.
