Reliable way to send current Retool app version in backend headers

Hi everyone,

I’m looking for guidance on how to reliably get the actual frontend version/revision a user is currently running in Retool, and ideally send it automatically in request headers at the resource level.

Context

We have a Retool app used internally, and users sometimes keep old tabs open for a long time.

Independently of breaking changes, we want to always log which frontend version the user is actually using on our backend (for observability/debugging/audit purposes).

On top of that, in some cases we also ship changes that are effectively breaking for older tabs, so we’d like the option to enforce a minimum frontend version as well.

We already inject some headers at the resource level (for example, sending the performer/current user email), which is great because it applies to all queries using that resource and avoids updating every query manually.

What we tried

We tried using retoolContext.pageTag (the value we also display in the app UI).

At first it looked correct, but we discovered it doesn’t seem to represent the version the user originally loaded in their tab.

It appears to behave more like the current live version/tag, so when a query runs, the value is re-evaluated and resolves to the latest live version — even if the user is still on an old tab and hasn’t refreshed.

That means it’s not reliable for:

  • Logging the actual frontend version the user is currently running

  • Enforcing a minimum version when needed

Possible workaround (but not fully happy with it)

I think a workaround could be:

  • On page load, run a script and store the version in a variable/state value

  • Then use that stored value for all requests (so it stays stable for that tab/session)

The problem is: I can only seem to reference that kind of variable/state in the query context, not in the resource-level header configuration.

So if I go this route, I’d need to manually add the header to every query, which is exactly what I’m trying to avoid.

My questions

  1. Is there a reliable Retool-provided value for the exact app version/revision loaded in the user’s current tab (not just the latest live version)?

  2. Is there any way to reference app state / variables / temporary state / script-generated values from the resource context (for resource-level headers)?

  3. Does Retool automatically send any header that already includes app version/revision/page tag info?

  4. What is the recommended pattern if we want to:

    • always log the actual frontend version used by the client, and

    • optionally enforce a minimum version from the backend side,
      while avoiding manual changes in every query?

Thanks a lot — even a workaround or recommended pattern would be super helpful.

Hello @Nazim_Belkaid,

Unfortunately there is no easy native way to do this. This functionality has been requested by other users and we have some open tickets for our engineering team to make this easier for end users.

If the goal is to let users know when their current app is out of date so they can refresh the page and update to the current latest published version, possible steps for this could be:

  • On page load, capture retoolContext.pageTag into a variable (e.g. loadedVersion).
  • Create a query that calls your backend (or Retool's API if accessible) to fetch the current live version, set to run on an interval (e.g. every 60 seconds).
  • Compare the result against loadedVersion — if they differ, show a banner or modal prompting the user to refresh.

retoolContext.pageTag is the only built-in option, and its behavior varies by context:

  • In edit mode, it always returns "latest" — not useful.
  • In preview/user mode with a published release, it correctly returns the semantic version number (e.g. "1.0.2"), but only if the URL doesn't include ?_releaseVersion=latest

When a new version is published, sending the semantic version number to a Retool table and having this table contain just one cell would be the simplest way to have a 'current live version' that can be queried and then compared against the retoolContext.pageTag to then trigger a modal/warning to users that are behind.