Issue with Manual Boot & CORS Error on First Login (Vite SPA) | Community
Skip to main content

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.

Hey ​@Dario Rojas 👋 Jacques here from Intercom Support. I hope all is well today!

Thank you for providing detailed information about the issue you are facing with the Intercom messenger in your React App. Based on the context and the troubleshooting steps you have already taken, it appears that the root cause of the problem is related to inconsistent CORS headers being returned by our servers during the initial boot process.

The CORS error you are encountering suggests that the Access-Control-Allow-Origin header is being set to * (wildcard) instead of your specific origin. This can indeed happen if the request's credentials mode is set to 'include', which does not allow the wildcard origin. Can you check that your Intercom settings are correctly configured to allow requests from your specific origin. This would involve checking your Intercom workspace settings to ensure that the domain is in your trusted domains.

If the errors persists, I’d recommend reaching out to our support team with the details of the issue, including the HAR files and any other relevant information. They may need to investigate in our servers why the wildcard Access-Control-Allow-Origin header is returned instead of the specific origin on initial requests.

As a temporary workaround, you might consider implementing a retry mechanism that attempts to reinitialise Intercom after a short delay if the initial boot fails due to CORS issues. This can help mitigate the impact of the inconsistent CORS headers.

Hope this helps!

Terms & ConditionsAccessibility statement