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 our AuthProvider. - Inside our
AuthProvider, a useEffect hook triggered by the user state change calls Intercom('boot', { userId, name, userHash }). - We've confirmed the
boot function is called with the correct user data. - We've confirmed
window.Intercom exists before calling boot. - We tried adding significant delays (up to 10 seconds using
setTimeout) before the boot call, 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
boot without the userHash (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_settings and https://api-iam.intercom.io/messenger/web/ping receive a 200 OK status, but the browser console shows a CORS error. The Access-Control-Allow-Origin response 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 in net::ERR_FAILED. - Successful Refresh/Load: The same requests to
/launcher_settings and /ping succeed. The Access-Control-Allow-Origin response 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.
