Popular Topics

For security reasons api keys should not be that open.Whitelist is a must feature for space security, if people get fired we are supposed to rotate all keys from all apps which is totally inconvenient and it is easier just to remove VPN access from the person.

Hi there! We’ve recently recieved reports from our support team that carousels aren’t displaying within the app. In our android code, we initialize intercom, and then if we are authenticated, we call loginIdentifiedUser after. This logic has been unchagned for a while and had worked for well over a year. Through debugging we have found that adding an artifical delay (9 seconds) between initialize and loginIdentifiedUser results in the carousesl to show again. Without the delay, login completes successfully (the callback returns a success), but the carousels don’t show.Is this expected behavior, or something on our end? Guidance would be greatly appreciated here  We’re using version 17.4.0 of intercom. 

Hi all, we use the Stripe integration from the Intercom App store, and I’ve found some cases in which not all of the Stripe data is populated when a subscription is created. Looking at the affected record in Stripe, I can see the event logs that reference data sent to Intercom but there are no errors present and the request body matches other Intercom users that DO have the subscription data. Is there any logging from the Stripe app in the Intercom marketplace where we can try and troubleshoot this? The best answer I got from Fin was “turn it on and off again” which might be the solution, but I’m hesitate to try that given how central this integration is to us. 

Hi everyone,My team is trying to refine our reporting, and we’re running into an issue where our "First Response Time" metrics are being skewed.We are trying to measure the speed of our agents picking up a chat specifically after Fin hands it off.However, we often have scenarios where Fin closes a chat without human interaction. Then, a few days later, we might manually check in on that user or follow up on the closed conversation. Currently, the reporting counts those intervening days as "wait time," which makes our response metrics look inaccurate (showing 2+ day response times for chats that were actually closed).Does anyone have a workaround or a specific filter setup that isolates "Active Fin Hand-offs" vs. "Manual Follow-ups on Closed Chats"? We want to see how fast we are responding to immediate needs, without the data being dragged down by our sporadic follow-ups.Thanks in advance!

Businesses in Jalandhar are exploring how Intercom can improve customer communication and engagement. When combined with professional digital marketing in Jalandhar, these tools help deliver targeted campaigns, personalized messages, and better follow-ups. I’d love to hear from the community—how do you use Intercom to improve local marketing efforts? For teams focusing on digital marketing Jalandhar campaigns, which strategies have given the best results in terms of engagement and conversions?  

Hello, I see that there is a Slack Intercom integration available here: https://www.intercom.com/help/en/articles/11534476-connect-your-slack-channelThe issue that I see though that is different from the use case that I am targeting is that Intercom tickets are initially created from Slack and not the other way around. I am trying to make it so that if a conversation/ticket is started in Intercom, it is automatically pinged in Slack. As you converse through Slack, those messages are also sent back and forth through Intercom. So my initial entry point would be Intercom versus Slack. Is there a way to do this?

I have the Slack integration working, so all messages sent via the live chat widget on our webiste are going to a Slack channel. How can I set it up so replies in a Slack thread go back to the Intercom conversation, and to the live chat widget? I have tried builing a “Teammate sends any message” workflow, and also a “Teammate adds a note” workflow, but neither one worked. Any suggestions?

I'm trying to get the user ID in order to make additional API calls, but I can't get it other than by performing an additional API call to look up the user's email address, which seems like a rather roundabout way of doing it?

I’m seeing an issue with a “blur” overlay being left on top of the conversation window when Intercom loads after calling [Intercom presentMessageComposer:NULL] or [Intercom presentMessageComposer:@”text”]This only happens when building on XCode and only when running on iOS 26. Any other combination (e.g. XCode 16 on iOS 26 or XCode 26 on an older iOS version) worksFeels like a race condition in the loading logic perhaps? But hard to investigate as it’s closed source.This happens on intercom-ios versions 16.6.2, 19.4.1 and several in betweenDoes anyone have any information or a workaround?  

We are trying to use official @intercom/messenger-js-sdk with our react app.https://www.npmjs.com/package/@intercom/messenger-js-sdkWe are calling Intercom instance in our App component Intercom({ app_id: ..., });and then updating user info when user data is available using following functions:import { boot, shutdown, update } from "@intercom/messenger-js-sdk"; when there is no user data we are calling boot with only id,boot({    "app_id": "...",})and if there is user data, we are passing required properties to boot functionboot({    "app_id": "...",    "user_id": "...",    "name": "...",    "email": "...@......",    "created_at": ....,}) 

  SDK Version: Intercom iOS SDK 19.4.1  Platform: iOS 26.1 Integration: Flutter (via intercom_flutter wrapper) Description:  The close button (X) on surveys does not respond to touch events on iOS. Users cannot dismiss surveys by tapping the close button and must complete the survey to proceed. Swiping down to dismiss still works.  Steps to Reproduce:  1. Initialize Intercom with valid credentials  2. Trigger an Intercom Survey (programmatically via presentContent:surveyWithId: or via auto-targeting)  3. Attempt to tap the close button (X) on the survey modal  4. Observe that the tap is ignored and the survey remains open  Expected Behavior:  The survey should close immediately when the close button is tapped.  Actual Behavior:  The close button does not respond to touch events. No c

Hi everyone,We’re currently using Tags as our main way of classifying conversations in Intercom (e.g. product area, issue type, billing, cancellations, etc.). It’s starting to feel a bit messy and hard to report on, so we’re considering moving to a small set of Conversation Attributes instead, and using Tags only for campaigns/one-offs and stuff like that.I’m looking for advice from teams who’ve actually done this: How did you decide which things should be Attributes vs Tags? Which Attributes do you find the most useful for reporting (e.g. issue type, product area, plan tier, outcome, churn reason)? Did you make any fields mandatory before closing a conversation? If so, how many before it became annoying for agents? How did you handle the transition period? Did you backfill old conversations or just start from a certain date? We’re also using Fin and I’d love any tips on that side: