We have included Intercom for messaging on our single-page-application. The widget is visible before and after login, so users can contact us from every page.
We boot the Intercom widget with the app_id parameter, before the user is authenticated
window.Intercom('boot', { app_id: APP_ID })
After the user has logged in on our site, we update the session with
window.Intercom(‘update’, {
intercom_user_jwt: <jwt>,
name: <user name>
})
If the user has not touched the Intercom widget before login, everything works fine. The conversation history is loaded, once the user opens Intercom.
If the user opened the Intercom widget before login (or started a new conversation in ‘visitor’ state), the conversation history is NOT loaded after authentication. To see the conversation history, the entire page must be reloaded.
Browser development tools show, that the request to load the conversations is done exactly once, after opening the Intercom widget for the first time, and is not repeated once the user has been authenticated.
According to the API documentation the widget should fetch messages after an update to the user info.
The only difference is, that we are authenticating the user via JWT.
Is this a known issue that is being addressed?
Is there a workaround to force the Intercom widget to refresh the conversation history after a user has been authenticated?
Thanks for your help
Best answer by Sean M
Hi @martin_hochstrasser_ergon, Seán here from the Intercom engineering support team 👋
What you’re seeing is consistent with how the Messenger can behave when it has already initialized and fetched data for an anonymous/visitor session and then you “upgrade” the session to an authenticated user without a full re-init.
A couple of key points from Intercom’s own docs:
In an SPA, an Intercom('update', …) is supposed to simulate a refresh and “check for new messages”. Intercom API Developer Docs+1
With JWT-based Messenger Security, Intercom explicitly describes the “happy path” for showing a user’s historical conversations as: Messenger is rebooted with Intercom('boot') and a valid JWT. Intercom
Because the Messenger has already fetched conversations once (for the visitor) and doesn’t refetch after you authenticate, the most reliable workaround is to treat “login” as a session swap and do a shutdown + boot (i.e., a “hard reboot” of the Messenger) rather than only update.
Workaround: shutdown → boot as authenticated user
On successful login, do this sequence:
// Visitor / logged-out state window.Intercom('boot', { app_id: APP_ID });
// ... later, after login succeeds and you have a fresh JWT ... function onLogin({ jwt, userId, email, name }) { // Optional: close any open messenger UI before swapping identity window.Intercom('hide');
// Clear the current (visitor) session in the messenger window.Intercom('shutdown');
// Boot a *new* session as the authenticated user window.Intercom('boot', { app_id: APP_ID, intercom_user_jwt: jwt,
// If you have them, include identifiers outside the JWT too // (Intercom SPA docs recommend always including user_id/email on updates/boots) user_id: userId, email: email, name: name, });
// Optional: trigger a “check for messages” window.Intercom('update'); }
Why this helps:
shutdown resets Intercom to a “clean state” for another user/session. Intercom+1
For JWT security, Intercom indicates the user’s history appears once the Messenger is rebooted with boot + valid JWT.
Hi @martin_hochstrasser_ergon, Seán here from the Intercom engineering support team 👋
What you’re seeing is consistent with how the Messenger can behave when it has already initialized and fetched data for an anonymous/visitor session and then you “upgrade” the session to an authenticated user without a full re-init.
A couple of key points from Intercom’s own docs:
In an SPA, an Intercom('update', …) is supposed to simulate a refresh and “check for new messages”. Intercom API Developer Docs+1
With JWT-based Messenger Security, Intercom explicitly describes the “happy path” for showing a user’s historical conversations as: Messenger is rebooted with Intercom('boot') and a valid JWT. Intercom
Because the Messenger has already fetched conversations once (for the visitor) and doesn’t refetch after you authenticate, the most reliable workaround is to treat “login” as a session swap and do a shutdown + boot (i.e., a “hard reboot” of the Messenger) rather than only update.
Workaround: shutdown → boot as authenticated user
On successful login, do this sequence:
// Visitor / logged-out state window.Intercom('boot', { app_id: APP_ID });
// ... later, after login succeeds and you have a fresh JWT ... function onLogin({ jwt, userId, email, name }) { // Optional: close any open messenger UI before swapping identity window.Intercom('hide');
// Clear the current (visitor) session in the messenger window.Intercom('shutdown');
// Boot a *new* session as the authenticated user window.Intercom('boot', { app_id: APP_ID, intercom_user_jwt: jwt,
// If you have them, include identifiers outside the JWT too // (Intercom SPA docs recommend always including user_id/email on updates/boots) user_id: userId, email: email, name: name, });
// Optional: trigger a “check for messages” window.Intercom('update'); }
Why this helps:
shutdown resets Intercom to a “clean state” for another user/session. Intercom+1
For JWT security, Intercom indicates the user’s history appears once the Messenger is rebooted with boot + valid JWT.
The Workaround described by you does trigger a reload of the messages when opening the Intercom launcher again, but it has a big drawback:
When using Intercom(‘update’, …) to update the session with the JWT authenticated user, a previous conversation that has been started as ‘visitor’ is automatically associated with the authenticated user and visible in the conversation history.
If we use the workaround with Intercom(‘shutdown’) followed by Intercom(‘boot’, ...), the conversation is lost to the user and is not associated with the user account. I think this happens, because Intercom(‘shutdown’) completely clears all the information from the browser local storage.
Is there a way to workaround the issue of the not updated conversation history after authentication and still have the functionality of the previous conversation being associated with the authenticated user?
I tried to do Intercom(‘update, ...) followed by Intercom(‘shutdown’) and Intercom(‘boot’, ...) but the conversation is still lost.
