Short lived JWT refresh on mobile using react-native-intercom SDK | Community
Skip to main content
Answered

Short lived JWT refresh on mobile using react-native-intercom SDK

  • March 18, 2026
  • 1 reply
  • 98 views
S

I’ve been trying to get Intercom to work with a JWT, but seems like it doesn’t work on the Android. 

Our JWT has about 5 mins TTL. 

I’m refreshing the JWT just before launching the Intercom and, in the background, refreshing the token every 4-5 mins to avoid JWT expiring mid-session. But turns out the SDK on Android does not use the new JWT even if we do

Intercom.setUserJwt(refreshedToken) 

The same thing works on iOS though, just not on Android. 

Has anyone had any luck with a short lived JWT working on Android or React Native? 

Best answer by Dara K

Hey ​@Sudarshan Bhat 

Short-lived JWTs are supported on Android and React Native, there isn’t a platform-specific limitation documented, but there are a couple of important details in how the Android SDK uses them.

How the Android SDK expects JWTs to be used
From the native docs, the pattern is:

// Kotlin / Android native
Intercom.client().setUserJwt("your_jwt_token_from_server")
// then register / log in the user

Once set, the SDK attaches that JWT to every request until you replace it with a new one via another setUserJwt(...) call. The token is validated on each request, not just at boot.

Given that:

  1. Your overall pattern is correct, but 5 minutes is very aggressive

    • A 5-minute TTL means any gap in your refresh loop (app backgrounded, device asleep, flaky network) can easily leave Android making a request with an expired token.
    • We generally recommend aligning the JWT exp with your app session length (e.g. 30–60 minutes, or whatever your own auth session is), and then refreshing when your app’s auth/session refreshes.

  2. On Android, the new JWT is only used for requests that happen after you call setUserJwt()
    Things to double-check in your implementation:

    • Make sure Intercom.setUserJwt(refreshedToken) is called before any call that might touch Intercom (login, updateUser, displayMessenger, etc.), not just on an interval in the background.
    • Don’t call login/register again with stale state after you’ve set the new JWT – if you log the user in again without re-setting the JWT first, those calls can still be made under the old token.

  3. How to debug if Android is still ignoring the new token

    • In your workspace, go to Settings → Messenger → Security → Installation logs and look at the recent Android entries. You should see the JWT payload + exp for each request – if Android is still sending the old token after your refresh, we can treat that as a bug in the RN wrapper.
    • If those logs show the new token but you still get “expired/invalid JWT” errors, then the issue is on the backend side (e.g. clock drift or too-short TTL).

Practically, I’d suggest:

  • Bump the JWT TTL to match your app session (e.g. 30–60 minutes).
  • On login and on any auth refresh, fetch a fresh Intercom JWT and immediately call: 
    Intercom.setUserJwt(newToken);
    before any further Intercom calls from Android.

1 reply

D
Intercom Team
Forum|alt.badge.img+5
  • Dara KIntercom Team
  • Intercom Team
  • Answer
  • March 27, 2026

Hey ​@Sudarshan Bhat 

Short-lived JWTs are supported on Android and React Native, there isn’t a platform-specific limitation documented, but there are a couple of important details in how the Android SDK uses them.

How the Android SDK expects JWTs to be used
From the native docs, the pattern is:

// Kotlin / Android native
Intercom.client().setUserJwt("your_jwt_token_from_server")
// then register / log in the user

Once set, the SDK attaches that JWT to every request until you replace it with a new one via another setUserJwt(...) call. The token is validated on each request, not just at boot.

Given that:

  1. Your overall pattern is correct, but 5 minutes is very aggressive

    • A 5-minute TTL means any gap in your refresh loop (app backgrounded, device asleep, flaky network) can easily leave Android making a request with an expired token.
    • We generally recommend aligning the JWT exp with your app session length (e.g. 30–60 minutes, or whatever your own auth session is), and then refreshing when your app’s auth/session refreshes.

  2. On Android, the new JWT is only used for requests that happen after you call setUserJwt()
    Things to double-check in your implementation:

    • Make sure Intercom.setUserJwt(refreshedToken) is called before any call that might touch Intercom (login, updateUser, displayMessenger, etc.), not just on an interval in the background.
    • Don’t call login/register again with stale state after you’ve set the new JWT – if you log the user in again without re-setting the JWT first, those calls can still be made under the old token.

  3. How to debug if Android is still ignoring the new token

    • In your workspace, go to Settings → Messenger → Security → Installation logs and look at the recent Android entries. You should see the JWT payload + exp for each request – if Android is still sending the old token after your refresh, we can treat that as a bug in the RN wrapper.
    • If those logs show the new token but you still get “expired/invalid JWT” errors, then the issue is on the backend side (e.g. clock drift or too-short TTL).

Practically, I’d suggest:

  • Bump the JWT TTL to match your app session (e.g. 30–60 minutes).
  • On login and on any auth refresh, fetch a fresh Intercom JWT and immediately call: 
    Intercom.setUserJwt(newToken);
    before any further Intercom calls from Android.
Terms & ConditionsAccessibility statement