All Collections
Custom Actions and Objects
Best practices
Custom Actions security and best practices
Custom Actions security and best practices
Learn about the handling of Custom Action storage, authorization and execution.
Beth-Ann Sher avatar
Written by Beth-Ann Sher
Updated over a week ago


Tokens are stored as part of the header configuration. For these values, we encrypt data at rest. Read more about security at Intercom here.


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.

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

Did this answer your question?