Storage
Tokens are stored as part of the header configuration. For these values, we encrypt data at rest. Read more about security at Intercom here.
Authorization
Custom Actions support both fixed and dynamic tokens for authentication. You can set up and manage your authentication tokens that you want to use in the request, which can then be added to the header.
Request Execution
All request configurations (Body, URL and Headers) are encrypted at rest.
Our backend sends all requests. Which means we do not make any API calls from the browser. For example, when a user triggers an action, this action is triggered by the Intercom system and not the UI.
Important: Third-party data is not validated by Intercom, and your Custom Action may overwrite data you've stored in Intercom. You should ensure that you trust the data returned from a Custom Action.
What IP addresses does Intercom send Custom Action requests from?
You may need to allowlist the following Intercom IP addresses (which we send Custom Action, Canvas Kit and webhook requests from) in order to accept Intercom requests on your side. These are as follows:
USA:
34.231.68.152
34.197.76.213
35.171.78.91
35.169.138.21
52.70.27.159
52.44.63.161
Europe:
54.217.125.63
54.246.173.113
54.216.9.3
Australia:
52.63.36.185
3.104.68.152
52.64.2.165
Best Practices
Here’s how to create secure and safe connections with Custom Actions.
Identity Verification
For the most secure call, we recommend using ‘Email’ or ‘User ID’ on the People Object to match the user in your system.
Intercom currently only allows you to verify the email or user ID values coming from Messenger. We strongly encourage you to set up and enable Identity Verification.
Protection from data leaks
There are generally two ways data can be compromised:
A user updates one of their own attributes maliciously - For example, setting "user_shopify_id=123", where 123 is a victim's Shopify ID. Then this data is pushed or pulled from Shopify for ID 123, and it gets associated with the malicious user in Intercom.
A user manipulates data in a third party, and a Custom Action pulls in compromised data to Intercom - For example, a user signs up for a third party using the phone number of a victim. Then a Custom Action queries the third party and syncs that phone number to a people attribute in Intercom. Now the user has overwritten their phone number with the victims.
To prevent this from happening, always test your Custom Action first before setting it live to ensure it’s configured correctly.
Key things to look at:
Make sure that your Custom Action is returning data relevant to the matched user.
Make sure that your data is being stored correctly in your mapped Intercom attributes.
Need more help? Get support from our Community Forum
Find answers and get help from Intercom Support and Community Experts