We are experiencing an issue with manually booting the Intercom messenger in our React Single Page Application (SPA) using react-use-intercom.
Goal: We need to initialize Intercom (using boot) only after a user successfully logs in, providing their userId and userHash (Identity Verification). The launcher should not appear on the login page.
Problem: The Intercom messenger launcher fails to appear on the very first login after starting the application. However, if we then refresh the page, or log out and log back in during the same browser session, the launcher appears and works correctly.
Implementation & Troubleshooting:
- We use
<IntercomProvider appId="..." autoBoot={false}>wrapping ourAuthProvider. - Inside our
AuthProvider, auseEffecthook triggered by the user state change callsIntercom('boot', { userId, name, userHash }). - We've confirmed the
bootfunction is called with the correct user data. - We've confirmed
window.Intercomexists before callingboot. - We tried adding significant delays (up to 10 seconds using
setTimeout) before thebootcall, but this did not solve the issue. - We have disabled ALL display conditions in our Intercom Messenger settings. The main "Show the Messenger launcher" toggle is ON.
- We tested calling
bootwithout theuserHash(disabling Identity Verification temporarily), and the problem still persists.
Key Finding (CORS Error): Using browser developer tools (Network tab), we found a critical difference between the failing first login and successful subsequent loads:
- Failing First Login: Requests to
https://api-iam.intercom.io/messenger/web/launcher_settingsandhttps://api-iam.intercom.io/messenger/web/pingreceive a200 OKstatus, but the browser console shows a CORS error. TheAccess-Control-Allow-Originresponse header is*(wildcard). The browser blocks this because the request's credentials mode is 'include' (likely due to cookies), which doesn't allow the*origin. This results innet::ERR_FAILED. - Successful Refresh/Load: The same requests to
/launcher_settingsand/pingsucceed. TheAccess-Control-Allow-Originresponse header correctly shows our specific origin (e.g.,http://localhost:3000).
Conclusion: It seems the root cause is that Intercom's servers are inconsistently responding with Access-Control-Allow-Origin: * to initial authenticated requests immediately following a manual boot call in our SPA environment. This invalid CORS header causes the browser to block essential requests needed to load the launcher.
Could you please investigate why the server might be sending the wildcard * CORS header instead of the specific origin on these initial requests after a manual boot?
We can provide HAR files or any other necessary details.
Thanks for your help.
