Hello team - With refreshAuthTokenOnNearExpiry: true on LiveboardEmbed, what is the trigger and timing for the proactive refresh? How far before exp should the iframe call getAuthToken? We only ever see getAuthToken called after GET /callosum/v1/session/isactive returns 401 — i.e. reactive at expiry, never before. Is that expected, or is the proactive timer not arming? AuthType.TrustedAuthTokenCookieless on cluster 26.7.0.cl, SDK 1.49.0. https://developers.thoughtspot.com/docs/Interface_LiveboardViewConfig#_refreshauthtokenonnearexpiry

message has been deleted

Solution: Based on the official docs,

autoLogin: true

is the control that tells the SDK to request a new token before token/session expiry;

refreshAuthTokenOnNearExpiry

is documented in the config API surface, but I could not find an official doc section that defines an exact lead-time (for example, “N seconds before exp”). So there is no documented guaranteed pre-expiry window you can rely on publicly right now. What is explicitly documented: -

getAuthToken

is the callback used by cookieless trusted auth to fetch tokens. -

autoLogin: true

is what enables refresh behavior before expiry. - Cookieless mode uses bearer token flow (no browser session cookie). Given your observation (

getAuthToken

only after

/callosum/v1/session/isactive

401), that behavior can be expected in practice if the SDK does not proactively schedule refresh in your runtime path/version combo, or if refresh is tied to activity/check cycles rather than a strict pre-exp timer. The docs do not publish the proactive trigger algorithm/timing for 1.49.0 + 26.7.0.cl, so you should treat “pre-exp refresh” as best-effort unless validated by ThoughtSpot support for that exact build. citeturn0commentary0 Suggestions: - Ensure

autoLogin: true

is set in

init()

(this is the documented switch for pre-expiry refresh behavior). citeturn0commentary0 - Keep

getAuthToken

fast and always returning a fresh token Promise. - If you need deterministic refresh timing, implement server-side token TTL policy + observability and open a ThoughtSpot support ticket with: - cluster version

26.7.0.cl

- SDK

1.49.0

- HAR showing

isactive

401 →

getAuthToken

sequence - whether iframe is idle/backgrounded when expiry occurs - If you want, I can help you build a minimal repro harness (single HTML + verbose SDK/network logging) to confirm whether proactive arming ever occurs in your environment. Docs:

@Aran above solution worked for you?

it did not, I have autoLogin: true is set in init(), and getAuthToken always returning a fresh token. Still no luck with proactively schedule refresh. We've just implemented it ourselves 30 seconds before expiry, but it's not really ideal

AutoLogin's token refresh is actually reactive, not proactive. There's no expiry-based proactive scheduler and no HostEvent to push a token early. So the proactive refresh you were expecting doesn't exist in the SDK. Can you try these ways instead? 1. Use TrustedAuthTokenCookieless, on expiry, it swaps the bearer token silently (no redirect). Cookie-based auth does a full re-login instead, which feels like a logout. 2. Request a longer token validity (validity_time_in_sec, e.g., 1800), so refreshes are rare. 3. Align your cluster's session/idle timeout to be ≥ the token validity — if the server session expires first, the SDK never gets a clean refresh window. 4. Set disableLoginRedirect: true so a missed refresh doesn't bounce the user to a login page. 5. Add handlers for AuthExpire / AuthFailure / AuthStatus.FAILURE and log them, if your token service is slow/erroring during the refresh handshake, that's what drops the user, and it's fixable server-side. 6. You can call resetCachedAuthToken() right before your proactive refresh to force the SDK to pick up a new token.

What about this flag? https://developers.thoughtspot.com/docs/Interface_LiveboardViewConfig#_refreshauthtokenonnearexpiry https://developers.thoughtspot.com/docs/Interface_SpotterEmbedViewConfig#_refreshauthtokenonnearexpiry

This flag is default on. It should work too.

I have getAuthToken logged and it never fires before an expiry always at 1800 seconds or after

We should look at the implementation code to conclude. Can you dm it to me? And if there is any way around, I will let you know.