Reference · built on requestConnectorSupport & service desks

Intercom

Conversations, tickets, contacts, and companies from Intercom, with webhook topics for each change.

Request accessPricing ↗

About

Intercom is a customer messaging platform. It holds contacts and companies, conversations across chat, email, and messenger channels, tickets with typed states, admins and teams, and help center articles. Intercom versions its REST API; the reference documents version 2.16 with regional hosts for the US, Europe, and Australia.

Through Fibric, an operator reads conversations and tickets as webhook topics arrive, checks the contact and company behind each one, and proposes a reply, a note, an assignment, or a state change for your approval. Each approved action leaves a receipt: what changed, why, and how to undo it.

This is a reference listing. It documents what Fibric would read from Intercom and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Conversations and their parts through the Conversations API and the conversation.user.created, conversation.user.replied, and conversation.admin.replied webhook topics
  • Tickets, ticket types, and ticket states, with ticket.created and ticket.state.updated webhook topics
  • Contacts and companies, including contact.user.created, contact.lead.created, and contact.merged topics
  • Admins, teams, and away status reasons for assignment and coverage
  • Tags, segments, notes, and data attributes attached to contacts and conversations
  • Macros, help center articles, and reporting data export

Proposed actions

  • Target capability: propose a reply or an internal note through POST /conversations/{conversation_id}/reply with message_type comment or note
  • Target capability: propose closing, snoozing, reopening, or assigning a conversation through POST /conversations/{conversation_id}/parts
  • Target capability: propose a ticket state or assignee change through PUT /tickets/{ticket_id}
  • Target capability: propose adding or removing tags on a ticket, or converting a conversation to a ticket

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Triage new conversations by intent

    As conversation.user.created topics arrive, the operator reads the message and the contact record, proposes a team assignment and tags, and shows you the reason before anything moves.

    With Ticket Triage

  • Catch a first reply that is slipping

    The operator watches open conversations without an admin reply, drafts a first response from the thread, and proposes it through the reply endpoint for your sign-off.

    With First Response

  • Hand a bot conversation to a person

    When a conversation needs a human, the operator proposes an assignment to an admin or team with a note summarizing what was already asked.

    With Bot Handoff

  • Hold ticket states to a clock

    Tickets that sit in one state past a threshold are surfaced with a proposed state change or assignment through the tickets endpoint.

    With Breach Watch

Requirements

  • An Intercom workspace and a Developer Hub app with the permissions each webhook topic requires
  • The regional host that matches your workspace: api.intercom.io, api.eu.intercom.io, or api.au.intercom.io
  • A public HTTPS endpoint to receive webhook notifications signed with X-Hub-Signature
  • An admin_id to attribute replies and conversation management actions
Authentication
A private app Access Token from the Developer Hub, or OAuth for a public app, sent as a Bearer token in the Authorization header.

Limits

  • Rate limits are 10,000 calls per minute per app and 25,000 per workspace, spread over 10-second windows
  • Some webhook topics are tied to more than one permission; a subscription needs at least one of them
  • Webhook signatures use SHA-1 HMAC with the app's client_secret; verification happens on your side
  • This listing covers the documented REST API and webhook topics; Messenger and Fin front-end surfaces are out of scope

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Intercom ↗

Questions and answers

Which Intercom webhook topics does this connector listen to?
The conversation, ticket, and contact topics: for example conversation.user.created, conversation.admin.replied, conversation.admin.closed, ticket.created, ticket.state.updated, and contact.user.created. Each topic needs the matching permission on the Developer Hub app. Intercom signs every notification with an X-Hub-Signature header.
Can the connector reply on behalf of a contact?
The reply endpoint accepts type admin or user, so a reply can be posted from an admin or on behalf of a contact. Fibric proposes replies as an admin, with the note option for internal comments. You approve before anything is sent.
Does Intercom have regional API hosts?
Yes. The reference lists api.intercom.io, api.eu.intercom.io for Europe, and api.au.intercom.io for Australia. Use the host that matches where your workspace is hosted.
Ask about Intercom

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Intercom through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy