We are hitting repeated 429 errors on our published app, on the query execution endpoint (executeV2), with the message:
"Too many requests to this resource; try again soon"
The app URL is on a sandbox-[id].retool.app domain (agent-vite path) — I believe this means our app is running on Retool's newer "agent sandbox" app-building architecture, but I would like you to confirm that.
This happens during normal use of the published app (not in the editor) — specifically:
Running a search feature that returns a large number of results (100+) — repeating the exact same search gives fewer results each time (e.g. 149, then 120, then 112 on consecutive attempts), which looks like some of the underlying requests are being silently rate limited and dropped mid search.
Saving a measurement/record has also failed with the identical 429 error at the same time.
Our own backend (hosted on Render) is nowhere near capacity when this happens, and the error is coming from your retool.app domain, so I understand the limit is being applied on Retool's side, upstream of our own infrastructure.
Could you tell us:
Which specific rate limit is being applied to our workspace/app (requests per minute or a points-based system), and whether it differs for the agent sandbox architecture vs. the standard app builder.
Whether this limit can be raised for our workspace/plan, and if so, what the process is.
Whether this limit is shared across ALL usage in our workspace (all users, all apps) or scoped per-app/per-user, since we want to understand whether unrelated activity elsewhere in our workspace could be contributing to this.
Happy to provide our workspace ID, the exact job/request IDs, or timestamps if that helps you look into it.START HERE TO GET USEFUL FEEDBACK FASTER-->
Repeated 429 'Too many requests to this resource; try again soon' errors are occurring on the executeV2 query endpoint of a published app running on a sandbox-[id].retool.app (agent-vite) domain — surfacing both as searches that silently return progressively fewer results (149 → 120 → 112) and as failed record saves — and the request is to confirm the app architecture, identify the specific rate limit and whether it differs for that architecture, learn whether it can be raised, and understand whether the limit is scoped per-workspace, per-app, or per-user.
AI Response
The sandbox-[id].retool.app (agent-vite) domain does correspond to the new app builder — this is corroborated by the topic itself being classified under the new app builder, and the deployment is a Retool Cloud instance. That said, an extensive search of the public Retool documentation and Community forum did not surface any resource that affirmatively documents the specific executeV2 request rate limit, whether that limit differs between the new app builder and the classic builder, the process for raising it, or whether it is scoped per-workspace versus per-app/per-user. Because no published source directly and affirmatively answers these points, it would not be accurate to state a specific limit value or scope here. The most reliable path is to attach the workspace ID, affected job/request IDs, and precise timestamps (already offered) to this topic so the exact limit and any adjustment options can be confirmed against the specifics of this deployment, rather than inferred from unrelated limits such as RetoolDB, Retool API, email, or database connection-pool limits, none of which describe this particular executeV2 error.
Sources
The Community Team is testing out a new automation. Let us know if it's helpful (or not) by leaving a , , or . Or by marking this post as the "Solution"! Let us know if you have any feedback here.
Hey @CRB - thanks for reaching out! It sounds like you're specifically hitting our rate limit on the app-serving layer, which limits individual authenticated users to executing 100 requests in a 60 second window. The cache key is solely dependent on the userId, so activity across apps does contribute to the same limit.
This is currently a hard-coded limitation, but we're actively tuning it and will definitely document it publicly. We can probably engineer your app to circumvent it entirely, though! Is your search feature firing off resource queries in a loop? Or triggering on keystroke? That might explain the high volume.
Thanks for the quick response. Yes I am running a symbol search on drawings. This limitiation has been evident on drawings with large numbers of counts. In excess of 100.
, 
, or 
. Or by marking this post as the "Solution"! Let us know if you have any feedback 