This integration is certified by Stitch. For support, contact Stitch support.
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 integration, including release status, useful links, and the features supported in Stitch.
| STITCH | |||
| Release Status |
Released |
Supported By | |
| Stitch Plan |
Paid |
||
| DATA SELECTION | |||
| Table Selection |
Unsupported |
Column Selection |
Unsupported |
| REPLICATION SETTINGS | |||
| Anchor Scheduling |
Supported |
Advanced Scheduling |
Unsupported |
| Table-level Reset |
Unsupported |
Configurable Replication Methods |
Unsupported |
| TRANSPARENCY | |||
| Extraction Logs |
Unsupported |
Loading Reports |
Supported |
Connecting Intercom
Intercom setup requirements
To set up Intercom in Stitch, you need:
- A paid Stitch plan. While those currently in the Free Trial will also be able to set up Intercom, replication will be paused until a paid plan is selected after the trial ends.
-
Your Intercom App ID. You can find your Intercom App ID by following these instructions.
Step 1: Add Intercom as a Stitch data source
- Sign into your Stitch account.
-
On the Stitch Dashboard page, click the Add Integration button.
-
Click the Intercom icon.
-
Enter a name for the integration. This is the name that will display on the Stitch Dashboard for the integration; it’ll also be used to create the schema in your destination.
For example, the name “Stitch Intercom” would create a schema called
stitch_intercomin the destination. Note: Schema names cannot be changed after you save the integration. - In the Intercom App ID field, enter your Intercom App ID.
Step 2: Define the historical sync
The Sync Historical Data setting will define the starting date for your Intercom integration. This means that data equal to or newer than this date will be replicated to your data warehouse.
Change this setting if you want to replicate data beyond Intercom’s default setting of 1 year. For a detailed look at historical replication jobs, check out the Syncing Historical SaaS Data guide.
Step 3: Create a replication schedule
In the Replication Frequency section, you’ll create the integration’s replication schedule. An integration’s replication schedule determines how often Stitch runs a replication job, and the time that job begins.
Intercom integrations support the following replication scheduling methods:
To keep your row usage low, consider setting the integration to replicate less frequently. See the Understanding and Reducing Your Row Usage guide for tips on reducing your usage.
Step 4: Authorize Stitch to Access Intercom
Lastly, you’ll be directed to Intercom’s website to complete the setup.
- If you aren’t already logged into Intercom, you’ll be prompted to do so.
- Next, a screen requesting access to Intercom will display. Note: Stitch will only ever read your data.
- Click Connect.
- After the authorization process successfully completes, you’ll be redirected back to Stitch.
- Click All Done.
Initial and historical replication jobs
After you finish setting up Intercom, its Sync Status may show as Pending on either the Stitch Dashboard or in the Integration Details page.
For a new integration, a Pending status indicates that Stitch is in the process of scheduling the initial replication job for the integration. This may take some time to complete.
Initial replication jobs with Anchor Scheduling
If using Anchor Scheduling, an initial replication job may not kick off immediately. This depends on the selected Replication Frequency and Anchor Time. Refer to the Anchor Scheduling documentation for more information.
Free historical data loads
The first seven days of replication, beginning when data is first replicated, are free. Rows replicated from the new integration during this time won’t count towards your quota. Stitch offers this as a way of testing new integrations, measuring usage, and ensuring historical data volumes don’t quickly consume your quota.
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 schemas
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.