Connection summary
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.
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
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
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
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.