This version of Intercom reached end of life on January 31, 2021 and is no longer functioning.
Upgrade to the latest version (v2) to continue replicating data.
Intercom integration summary
Stitch’s Intercom integration replicates data using the Intercom REST API (V1.0). Refer to the Schema section for a list of objects available for replication.
Intercom feature snapshot
A high-level look at Stitch's Intercom (v02-02-2016) integration, including release status, useful links, and the features supported in Stitch.
| STITCH | |||
| Release status |
Sunset on January 31, 2021 |
Supported by | |
| Stitch plan |
Standard |
API availability |
Not available |
| Singer GitHub repository |
Not applicable |
||
| REPLICATION SETTINGS | |||
| Anchor Scheduling |
Supported |
Advanced Scheduling |
Unsupported |
| Table-level reset |
Unsupported |
Configurable Replication Methods |
Unsupported |
| DATA SELECTION | |||
| Table selection |
Unsupported |
Column selection |
Unsupported |
| Select all |
Unsupported |
||
| TRANSPARENCY | |||
| Extraction Logs |
Unsupported |
Loading Reports |
Supported |
Intercom replication
Intercom Replication and Attribution Windows
Every time Stitch runs a replication job for Intercom, the last 30 days’ worth of data will be replicated for these tables:
-
companies -
company_segments -
users
Stitch replicates data in this way to account for updates made to existing records within the default attribution window of 30 days, thus ensuring you won’t make decisions based on stale (or false) data. As a result, you may see a higher number of replicated rows than what’s being generated in Intercom.
Setting the Replication Frequency to a higher frequency - like 30 minutes - can result in re-replicating recent data and contribute to greater row usage. Selecting a lower frequency can help keep your row count low.
Intercom table reference
Schemas and versioning
Schemas and naming conventions can change from version to version, so we recommend verifying your integration’s version before continuing.
The schema and info displayed below is for version 02-02-2016 of this integration.
Table and column names in your destination
Depending on your destination, table and column names may not appear as they are outlined below.
For example: Object names are lowercased in Redshift (CusTomERs > customers), while case is maintained in PostgreSQL destinations (CusTomERs > CusTomERs). Refer to the Loading Guide for your destination for more info.
admins
| Replication Method : |
Full Table |
Primary Key  :
|
id |
| API endpoint : | |||
The admins table contains info about the admins and teams in your Intercom account.
|
id
The admin or team ID. Reference: |
|
|
type
The admin type. This value will be either |
|
|
name
The name of the admin or team. |
|
|
email
The email address of the admin. This will be |
|
|
away_mode_enabled
Indicates if the admin is currently set in away mode. |
|
|
away_mode_reassign
Indicates if the admin is set to automatically reassign new conversations to the app’s default inbox. |
|
|
team_ids
A list of the IDs of the teams the admin is a part of.
|
companies
| Replication Method : |
Key-based Incremental |
Replication Key  :
|
updated_at |
|
Primary Key :
|
id |
API endpoint : |
The companies table contains info about the companies (or commercial organizations) that use your Intercom product.
Custom Attributes
If applicable, Stitch will replicate custom fields related to companies in Intercom.
|
id
The Intercom-defined company ID. Reference: |
|||
|
updated_at
The time the company was last updated. |
|||
|
company_id
The ID that you assigned to the company. |
|||
|
created_at
The time the company was added to Intercom. |
|||
|
remote_created_at
The time the company was created by you. |
|||
|
name
The name of the company. |
|||
|
custom_attributes
If applicable, the custom attributes you’ve applied to the company. |
|||
|
session_count
The number of recorded sessions for the company. |
|||
|
monthly_spend
The amount of revenue the company generates for your business. |
|||
|
user_count
The number of users in the company. |
|||
|
plan
The name of the plan associated with the company. |
|||
|
type
The value of this field will be |
|||
|
segments
A list of the IDs of the segments associated with the company.
|
|||
|
tags
A list of the IDs of the tags associated with the company.
companies (table), tags (attribute)
|
company_segments
| Replication Method : |
Full Table |
Primary Key :
|
id |
| API endpoint : | |||
The company_segments table contains info about company segments. A segment is a group of users that are defined by a set of rules.
|
id
The segment ID. Reference: |
|
updated_at
The time the segment was last updated. |
|
created_at
The time the segment was created. |
|
name
The name of the segment. |
|
person_type
The type of record. This will either be |
|
type
The value of this field will be |
contacts
| Replication Method : |
Key-based Incremental |
Replication Key :
|
updated_at |
|
Primary Key :
|
id |
API endpoint : |
The contacts table contains info about the logged-out users, or leads, of your Intercom app.
Note: contacts is equivalent to the leads object in Intercom’s API. See Intercom’s documentation for more info.
Custom Attributes
If applicable, Stitch will replicate custom fields related to contacts (leads) in Intercom.
|
id
The lead’s Intercom-defined ID. Reference: |
||||||||||
|
updated_at
The time the lead was last updated. |
||||||||||
|
created_at
The time the lead was added to Intercom. |
||||||||||
|
user_id
An Intercom-generated ID for the lead. |
||||||||||
|
email
The email associated with the lead. |
||||||||||
|
phone
The phone number associated with the lead. |
||||||||||
|
name
The name of the lead. |
||||||||||
|
last_request_at
The time the lead last made a request. |
||||||||||
|
avatar
Details about the avatar associated with the lead.
|
||||||||||
|
unsubscribed_from_emails
Indicates if the lead is unsubscribed from emails. |
||||||||||
|
location_data
Details about the lead’s location.
|
||||||||||
|
user_agent_data
Data about the last user agent the lead was seen using. |
||||||||||
|
last_seen_ip
The IP address the lead last visited your application from. |
||||||||||
|
companies
Details about the companies the lead is associated with.
|
||||||||||
|
social_profiles
Details about the social profiles the lead is associated with.
|
||||||||||
|
segments
Details about the segments the lead is associated with.
|
||||||||||
|
tags
Details about the tags the lead is associated with.
contacts (table), tags (attribute)
|
conversations
| Replication Method : |
Key-based Incremental |
Replication Key :
|
updated_at |
|
Primary Key :
|
id |
API endpoint : |
The conversations table contains info about user conversations, or conversations initiated by your end-users.
Conversation Parts
To reconstruct an entire conversation, use the conversation_parts associated with the conversation. These are the individual elements - actions, messages, and so on - that make up a conversation.
If your destination doesn’t natively support nested data structures, a subtable named conversations__conversation_parts will be created. More info on this table can be found below.
|
id
The conversation ID. |
|||||||||||||||
|
updated_at
The time the conversation was last updated. |
|||||||||||||||
|
created_at
The time the conversation was created. |
|||||||||||||||
|
waiting_since
An epoch timestamp that indicates the last time a customer responded to an admin, or the time a customer started waiting for a response. Note: According to Intercom’s documentation, this field may sometimes contain a value that is 2000 years in the future. This can occur when the last person to respond was an admin or when the conversation was closed aver a customer response. |
|||||||||||||||
|
snoozed_until
If set, this is the time in the future that the conversation will be marked as |
|||||||||||||||
|
state
The current state of the conversation. Possible values are:
|
|||||||||||||||
|
conversation_message
Details about the message that started the conversation.
|
|||||||||||||||
|
conversation_parts
Details about the individual elements that make up the conversation.
|
|||||||||||||||
|
total_count
The total number of conversation parts in the conversation. |
|||||||||||||||
|
user
Details about the user or lead involved in the conversation.
|
|||||||||||||||
|
assignee
Details about the admin assigned to the conversation.
|
|||||||||||||||
|
customers
Details about the customers (users or leads) involved in the conversation.
|
|||||||||||||||
|
open
Indicates whether a conversation is open ( |
|||||||||||||||
|
read
Indicates whether a conversation has been read. |
|||||||||||||||
|
tags
The tags associated with the conversation.
|
|||||||||||||||
|
type
The value of this field will be |
segments
| Replication Method : |
Full Table |
Primary Key :
|
id |
| API endpoint : | |||
The segments table contains info about the segments - or groups of users defined by a set of rules - in your Intercom account.
|
id
The segment ID. Reference: |
|
updated_at
The time the segment was last updated. |
|
created_at
The time the segment was created. |
|
name
The name of the segment. |
|
person_type
The type of record. This will either be |
|
type
The value of this field will be |
tags
| Replication Method : |
Full Table |
Primary Key :
|
id |
| API endpoint : | |||
The tags table contains info about the tags in your Intercom account.
|
id
The tag ID. Reference: |
|
name
The name of the tag. |
|
type
The value of this field will be |
users
| Replication Method : |
Key-based Incremental |
Replication Key :
|
updated_at |
|
Primary Key :
|
id |
API endpoint : |
The users table contains info about the users in your Intercom account.
Custom Attributes
If applicable, Stitch will replicate custom fields related to users in Intercom.
|
id
The user ID. Reference: |
||||||||||
|
updated_at
The time the user was last updated. |
||||||||||
|
created_at
The time the user was added to Intercom. |
||||||||||
|
signed_up_at
The time the user signed up. |
||||||||||
|
email
The email address associated with the user. |
||||||||||
|
name
The full name of the user. |
||||||||||
|
phone
The phone number associated with the user. |
||||||||||
|
last_request_at
The time the user last made a request. |
||||||||||
|
session_count
The number of sessions recorded for the user. |
||||||||||
|
avatar
Details about the avatar associated with the user.
|
||||||||||
|
unsubscribed_from_emails
Indicates if the user is unsubscribed from emails. |
||||||||||
|
location_data
Details about the user’s location.
|
||||||||||
|
user_agent_data
Data about the last user agent the user was seen using. |
||||||||||
|
last_seen_ip
The IP address the user last visited your application from. |
||||||||||
|
pseudonym
If the user was previously a lead, this field will contain the pseudonym used. Ex: |
||||||||||
|
anonymous
Indicates if the user is a lead. This will always be |
||||||||||
|
companies
Details about the companies the user is associated with.
|
||||||||||
|
social_profiles
Details about the social profiles the user is associated with.
|
||||||||||
|
segments
Details about the segments the user is associated with.
|
||||||||||
|
tags
Details about the tags the user is associated with.
users (table), tags (attribute)
|
||||||||||
|
type
The value of this field will be |
| Related | Troubleshooting |
Questions? Feedback?
Did this article help? If you have questions or feedback, feel free to submit a pull request with your suggestions, open an issue on GitHub, or reach out to us.