Popular Topics

When an admin sends an outbound email from Intercom, the message exists as a message object but no conversation is created until the recipient replies. Because of this, the API cannot retrieve the outbound email via the conversations API (GET /conversations/{id}) until a reply occurs.Request: allow the API to retrieve admin‑initiated outbound emails immediately after sending, even if the recipient has not replied yet. This would enable better auditing, logging, and integration workflows for outbound communications.

I’m working on an email reply automation tool using the Intercom REST API. I’m trying to retrieve the email history — the quoted text that appears collapsed behind the three dots (“…”) when a customer replies to an outbound email we’ve sent them. Three dots for expanding email historyFrom inspecting the network traffic, I can see that this data is retrieved via a private Ember API endpoint:curl 'https://app.intercom.com/ember/inbox/email_history?metadata_id=XXXXXXXXX&app_id=yyyyyyy Is there an equivalent method in the public REST API to access this email history or quoted content?I’ve already tried GET /conversations/{conversation_id}, but the response only includes the conversation parts - it doesn’t contain the quoted email thread (the hidden “three dots” section) in either the parts or metadata.To clarify, customers are replying directly to our outbound emails (sent via our own system, not through Intercom). When we fetch the resulting conversations through the API, we can see t

Hello everyone,I am facing an issue with Intercom Push Notification when it is a cold start (App is terminated, you receive a Push Notification and this notification will wake the App). While testing on Simulator that, if i am running my app from Xcode, terminate the App (on Simulator, not on Xcode), send a message to my test user, wait the push notification, receive it, tap on it but when i tap on it, Intercom Messenger does not opens the modal chat, it keeps me on my WorkListView (WorkList is a subview of RootView, that appears after SplashViews finish animation and transit to WorkListView).I have already made installation (API Key, API ID and Push Notifications are enabled on Settings > Channel > Messenger > Install > Install for Mobiles), Apple Developer is already configured, when i open the Messenger on my App, i can send and receive messages. When App is open but in background i am able to receive and wake the app in the correct modal Intercom window chat, but only t

Recently, a new "From" field/line was added at the top of the chat panel with a customer. Unfortunately, this element takes up almost half of the visible screen area in the chat view.While I understand this might have been introduced as part of a design refresh or to improve context visibility, in practice, it significantly hinders daily workflow: Drastically reduced readable area: Agents now have to scroll constantly just to read brief message threads. Slower response times: Managing multiple conversations becomes inefficient when key information and context are pushed out of the viewport. Could you please consider making this header more compact, collapsible, or giving us an option to customize/hide it? 

Hi everyone,I'm Marius from NEONA, a design lighting brand based in Cologne. We're currently rolling out Fin on our email channel — German language, mostly B2C — and I'm doing it solo for the first time.I'd like to connect with other companies in Germany or German-speaking markets running Intercom, ideally with Fin. Nothing confidential — I'm just curious how others have approached things like:splitting workflows by channel vs. by function where you draw the line between what Fin handles and what goes to a human German-language tone, and how you handle formality what you'd do differently if you started overHappy to share what we've run into as well — a few things came up that aren't covered in the docs.If any of this sounds familiar, drop a comment or send me a DM.Marius

Hi all — I'm doing some research on how teams measure AI resolution quality, and there's one thing I can't find anyone talking about.My understanding of the billing mechanic: a conversation counts as resolved either when the customer confirms it helped, or when they stop responding without asking for a human. The second case is the interesting one. Intercom does deduct the resolution if the customer reopens *that conversation* later, even across billing periods, which seems like a genuinely fair correction.But it only catches people who come back to the same thread. If someone reads Fin's answer, decides it didn't help, and emails support@ three days later — or calls, or starts a fresh chat — that's a new conversation. Nothing connects it to the original, and from what I can tell there's no way to see that pattern from inside Intercom, because Intercom can only see the Intercom channel.So my question: **has anyone here actually joined their email or phone support data against Fin's res

Hi Intercom Team,We're hitting intermittent errors from the REST API that appear out of the blue — not correlated with our request rate or any code change on our side — and that succeed when we retry a short while later.The responses come back as HTML (nginx), not the usual JSON. Two examples:404 Not Found — GET /companies/scroll, x-request-id: 000fb95rqvhcl5nf9to0 403 Forbidden — seen previously (HTML, no x-request-id / x-ratelimit-limit headers)We've increased our retry/backoff, which recovers most occurrences, but some still fail outright.This looks like prior reports:https://community.intercom.com/api-webhooks-23/getting-404-502-and-504-error-from-api-at-the-first-time-then-success-after-retry-10039 https://community.intercom.com/api-webhooks-23/api-requests-are-returning-403-4656Any help here would be pretty appreciated. Happy to share timestamps and more request IDs.Thanks,Faruq 

We've had the iOS Messenger down for ~2 months on our production app (React Native, @intercom/intercom-react-native 10.3.4, US workspace, appId m4e3h09o). Android works fine with the identical integration.Symptoms: the Messenger opens but content stays empty; the native console shows repeated "network error – the data couldn't be read because it isn't in the correct format" on update-user and fetch-composer-suggestions. curl to api.intercom.io succeeds, so it isn't connectivity — the SDK is receiving a response it can't parse (JSON deserialization failure).What we've already done: confirmed appId + iOS key resolve to the same workspace; ruled out init order, ATS, SSL pinning, duplicate packages and region routing.The telling part: a minimal, empty Expo project with the same appId/key loaded the Messenger correctly on one run, then reproduced the exact same error on a later run — with nothing changed locally. An identical client that passes and then fails with zero local changes points

Hi Intercom support,It seems like something quite big was added to the intercom-ios repo on Github, such that cloning the repo is now a >3GB download.(see https://api.github.com/repos/intercom/intercom-ios -- size: 3144481!)SwiftPM does deep clones, so a fresh build on xcode now takes several hours due to waiting for the intercom package.Can something be done about this?Cheers,Tom McLean