⚠️ Heads-up: User tokens expire after 30 days of inactivity — undocumented behavior + workaround

Tips
1

Hi everyone,

I ran into an issue recently with API tokens suddenly becoming invalid for users, and after digging into it with Bubble support, I wanted to share what I learned — since this behavior is currently not documented but intended by design.

:fire: The issue

I was using user tokens (with a 360-day expiration) in a 3rdParty-to-Bubble integration, expecting them to remain valid for the full duration. However, some tokens started failing unexpectedly — with no clear indication or error until the system broke.

:brain: What Bubble support confirmed

Bubble support told me the following:

  • User tokens are automatically invalidated after 30 days of inactivity.
  • This is by design, to avoid long-term memory leaks and enforce better security for dormant sessions.
  • As long as a user remains “active”, the session is extended by another 30 days. But 30 days dormant users get their token to expire.
  • Unfortunately, there’s no way to check in advance if a token is still valid — you only find out when it fails.

:white_check_mark: The workaround

I asked if there was any way to work around this, and here’s what support suggested:

“You should be able to work around this by scheduling a no-op workflow every week or so that reschedules itself, or by embedding a re-login flow into your automations.”

To keep a token alive for more than 30 days:

  • :hammer_and_wrench: Schedule a recurring no-op workflow (e.g. every 25–28 days) that makes an API call using the user’s token.
  • :white_check_mark: This counts as activity and resets the inactivity timeout.
  • :repeat_button: Alternatively, consider re-authenticating the user regularly, though this is less ideal for user experience.

:memo: TL;DR

  • User tokens expire after 30 days of inactivity, even if they were created with a 360-day lifespan.
  • There is no warning or visibility when a token is invalidated.
  • You can keep tokens alive with regular background activity using the token.

Hope this helps others avoid the same confusion. I also hope this behavior will be officially documented in Bubble’s API/token documentation in the future.

If anyone’s found other solutions or patterns, feel free to share them below! :backhand_index_pointing_down:

4 Likes
2

Hi @johann3, your post was super useful. Thank you!

Can you please clarify what is a “no-op workflow”?

3

Hi Gianluca

The idea is to schedule a workflow that uses the token to call a Bubble API.
This Bubble API is executing an API workflow that does nothing (no-op).
You only add an action “return data from API” and you include something like isTokenValid=true

If the token is valid, you get “true”

FYI, even with this in place, we still have users that get an invalid tokens. (Bubble support is investigating currently)

Managing the error (if isTokenValue=false then do something) help us to wipe out the token from database and to force login to generate a new token.

Hope this helps,

Johann

1 Like