> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rippit.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Intercom

> Technical reference for the Rippit Intercom data integration: authorization, regional hosts, API endpoints, and sync behavior.

A read-only OAuth integration that syncs Intercom conversations into Rippit on a schedule. For what applies to every integration, see [how data integrations work](/plg/data-integrations). For the security model, see [Data integration security](/security/data-integrations).

## Connection summary

|                                |                                                               |
| ------------------------------ | ------------------------------------------------------------- |
| Authorization                  | OAuth 2.0 authorization code grant                            |
| Scope parameter                | None. Permissions are fixed by the Intercom app configuration |
| Writes to Intercom             | None. No conversations, replies, notes, or tags created       |
| Credentials shared with Rippit | None. No password, no API token                               |
| Required Rippit role           | Workspace admin                                               |
| Regions                        | US, EU, AU                                                    |
| API version                    | Pinned to Intercom-Version `2.10`                             |
| Workspace identity             | Intercom app ID, confirmed after authorization                |
| Maximum historical backfill    | 90 days                                                       |
| Field selection limit          | 150 columns                                                   |

## Before you connect

**Pick your region first.** Intercom runs separate regional stacks, and the whole exchange has to happen on the one your workspace lives on. Selecting the wrong one fails at Intercom rather than connecting you to the wrong place.

| Region | Authorization host    | API host             |
| ------ | --------------------- | -------------------- |
| US     | `app.intercom.com`    | `api.intercom.io`    |
| EU     | `app.eu.intercom.com` | `api.eu.intercom.io` |
| AU     | `app.au.intercom.com` | `api.au.intercom.io` |

Because there is no scope parameter, Intercom's authorization screen is the authoritative statement of what you are granting. Read it before approving.

Rippit can read only what the authorizing account can read. Use a dedicated service account so you control what it can see and the connection does not break when someone leaves.

## Data handling

| Question                                            | Answer                                             |
| --------------------------------------------------- | -------------------------------------------------- |
| Is conversation content ingested, or only metadata? | Full message history for every synced conversation |
| Are custom attributes ingested?                     | Yes, and discovered automatically. See below       |
| Can Rippit modify Intercom?                         | No. No write code path exists                      |
| Is data used to train models?                       | No. Inference only                                 |

Intercom's schema endpoint does not list every custom attribute in use. Rippit samples live conversations to catch the rest, so attributes reach your table even when the API does not advertise them. Intercom's own **CX Score** is one example. Attributes created after you connect are picked up the same way.

## API endpoints

| Object                               | Endpoint                              | Method      |
| ------------------------------------ | ------------------------------------- | ----------- |
| Conversation discovery               | `/conversations/search`               | POST (read) |
| Conversation content                 | `/conversations/<id>`                 | GET         |
| Admins, for attribution              | `/admins`                             | GET         |
| Teams                                | `/teams`                              | GET         |
| Tags                                 | `/tags`                               | GET         |
| Calls, where Intercom calls are used | `/calls`                              | GET         |
| Contacts                             | `/contacts/<id>`                      | GET         |
| Custom attribute schema              | `/data_attributes?model=conversation` | GET         |

Conversations are read in two phases, which is why two endpoints appear.

**Discovery.** `/conversations/search` asks which conversations changed in a given time window, 150 per page. It returns conversation records with a message count but not the messages themselves. It uses `POST` because that is Intercom's search API contract; it returns data and changes nothing.

**Content.** Each conversation the search names is then fetched individually at `/conversations/<id>`, 5 concurrent. This is the call that returns `conversation_parts`, the actual message history.

The workflow: one search call per window, plus one `GET` per changed conversation.

**Contacts are fetched by ID only, never listed or searched.** Rippit takes the contact IDs attached to conversations it has already synced and retrieves those records one at a time, 10 concurrent. There is no sweep of your contact base, so a contact who never appears on a synced conversation is never read.

## Sync behavior

|                            |                                                                    |
| -------------------------- | ------------------------------------------------------------------ |
| Conversation sync          | Windowed search on `updated_at`, ascending, 150 per page           |
| Window width               | 15 minutes, up to 8 in flight                                      |
| Conversation content fetch | Per conversation by ID, 5 concurrent                               |
| Update handling            | A conversation with a new reply re-enters the window and refreshes |
| Expected latency           | Up to 3 hours                                                      |

Because the sync axis is `updated_at` and original timestamps do not change on refresh, your table can hold conversations older than the backfill window you set.

## Limiting ingestion scope

Set at connection time:

| Control         | Limit             |
| --------------- | ----------------- |
| Backfill window | Up to 90 days     |
| Field selection | Up to 150 columns |