Intercom AI integration: access, output, and current status

An Intercom AI integration is an app that reads or changes permitted Intercom records through Intercom's API. The proof is an identifiable app, exact permissions, one source-linked work product, a denied-operation test, and a working revocation path. Intercom's platform makes those pieces possible. A particular vendor must still prove its implementation.

FidelicAI does not currently offer an Intercom-connected production role. The production AI agent catalog lists each role's actual systems and limits, and none lists Intercom. A buyer should not be asked to authorize Intercom for FidelicAI today. Use Intercom's own product, hire a qualified integration builder for a custom app, or return when a published FidelicAI role names Intercom and the connection record below can be tested.

Which Intercom route fits the work?

Intercom's authentication guidance separates private and public apps. A private app working only with its owner's Intercom data uses an access token. A public app accessing other companies' Intercom data uses OAuth, the authorization flow that lets a customer approve a third-party app without handing over a private token.

Intercom also offers Fin, its own AI product for customer service. Fin establishes Intercom's native product capability. A third-party connection needs its own proof. Choose Fin for Intercom's native service automation, choose a custom app when the company will own the build, and choose a hired role only after its current role page names Intercom.

What do Intercom OAuth scopes permit?

An OAuth scope is a permission category granted to an app. Intercom's current OAuth scope list includes separate permissions for reading conversations, writing conversations, reading or writing tags, viewing people and companies, and viewing administrators. Intercom describes Write conversations as permission to reply to, mark as read, and close conversations.

These are object-and-action permissions. Intercom's published list does not document a scope for “only the conversation segments the workspace owner shares.” That narrower rule could be implemented as product logic, but it would not become an OAuth boundary merely because the product interface says “segment.” A credible vendor would need to show the filter, the records it excludes, the behavior when the filter fails, and a denied-record test.

The smallest useful read-only scope set depends on the work product. A customer-feedback brief may need Read conversations. It may also need a people or company permission if the accepted result groups evidence by customer or account. Read admins may be needed for assignment or teammate attribution. Each extra object needs a reason tied to the result.

Write permissions require a separate business decision. An internal note, a customer-visible reply, marking a conversation read, closing it, and changing tags have different consequences. Intercom's Conversations API documents read and reply operations, including an admin note. The current FidelicAI catalog claims none of those operations for Intercom.

What output would prove the connection is useful?

Automated conversation reading can replace manual exporting, copying, and first-pass grouping for a defined review. People still decide whether the evidence is representative, whether a customer needs a reply, whether an issue should become product work, and what the company will say.

Consider a fictional software company called Northstar Ledger. Its product owner wants a weekly evidence brief for one recurring checkout complaint. A useful read-only result would contain:

• the question the review was meant to answer;
• the Intercom conversation identifiers and direct source links;
• the approved date, inbox, and status filters;
• a short statement of the repeated problem;
• the distinct customer situations that should not be combined;
• the exact evidence supporting each observation;
• records excluded by the stated filter;
• unresolved contradictions and missing context;
• the person responsible for any customer reply or product decision;
• the next review date and the source window it will cover.

Northstar Ledger and every scenario detail are fictional. No customer result or measured accuracy is claimed. The accepted output is the source-linked brief; any wider claim that every conversation was understood remains unsupported. Done when: the reviewer can open every cited conversation, reproduce the filter, see which records were excluded, and identify each decision that still belongs to a person.

The broader outcome acceptance guide applies the same rule to a hired role. A chat answer can be helpful without becoming an auditable work product. The AI agent versus chatbot guide separates those two kinds of help.

How do you prove an Intercom connection?

Intercom documents public-app installation and uninstallation, including OAuth for third-party workspaces and an uninstall operation. A production proof should also cover token invalidation, cached data, queued jobs, saved outputs, and logs held outside Intercom. Copies already written to another approved system remain subject to that destination's retention and deletion rules after revocation.

A webhook is an event notification sent to an app. Intercom's webhook topics can notify an app about selected events, and each topic is tied to one or more permissions. A vendor must separately prove event receipt, verification, retries, duplicate handling, processing, the resulting work record, and the blocked-work route.

What data and error record should exist?

A connection record should answer the following before customer data moves:

• Is the app private or public, and who owns it?
• Which Intercom workspace and regional authorization host are used?
• Which OAuth permissions are approved, and what required output justifies each one?
• Which records can the API technically reach?
• Which narrower product filters are expected, and how are they tested?
• Which provider processes conversation content after it leaves Intercom?
• What content is stored, logged, cached, or sent to another work environment?
• How long is each copy retained, and who can delete it?
• Which writes are implemented, and which person approves each consequential write?
• What happens on 401, 403, 402, 429, validation failure, or a server error?
• How are access, queued work, stored copies, and credentials handled after revocation?

Intercom documents separate authorization, plan, validation, rate-limit, and server error responses. An API error alone leaves the operator unable to tell whether a weekly brief is incomplete or a customer-facing action failed, so the product record needs a blocked-work behavior for each consequential operation.

Intercom also documents different OAuth authorization hosts for US, EU, and Australian workspaces in its OAuth setup guide. Regional routing covers only one part of a data-residency statement. A vendor still needs to disclose its processors, destinations, storage, logs, retention, and deletion behavior. The current FidelicAI security record provides company-level boundaries; a future role would need an Intercom-specific connection record as well.

What does FidelicAI support today?

No current FidelicAI production role lists Intercom. FidelicAI therefore does not currently publish:

• an Intercom public app or installation URL;
• Intercom OAuth permissions requested by a production role;
• supported conversation, contact, tag, ticket, or admin reads;
• supported note, reply, read-state, close, tag, or ticket writes;
• webhook topics or delivery behavior;
• an Intercom-derived accepted work product;
• setup time, plan availability, rate handling, storage, retention, or revocation evidence.

A platform's inclusion in the current integration directory establishes platform context. The production role page establishes whether that role supports the platform. Use the AI agent buyer's guide to compare an existing product, a custom integration builder, a qualified person, and a ready role.

Questions buyers ask