Action - Update Contact
Reference manual for Intercom update action
Our new action is designed to keep your Intercom database accurate and up to date by updating existing contacts with the latest information. You can modify both standard and custom attributes such as name, email, phone, tags, or any other fields, ensuring your customer records remain consistent and relevant.
Please note that this action only updates existing contacts on your intercom, it will not create new contacts. Contact creation on intercom is happening automatically when a user uses intercom-enabled app, so most of the times there is no need to create new contacts ahead of time
When executed successfully, the action will:
- Update the specified contact in Intercom
- Return the updated record with all changed attributes
Limitations
While highly flexible, please note that:
- The contact must already exist in Intercom (this action does not create new contacts)
- Updates to custom attributes must match the schema defined in your Intercom workspace

What happens if I delete or archive a property in Intercom?
When you archive a custom attribute in Intercom, it becomes unavailable for use within your workspace. Intercom shows the following message during the archiving process:
Archiving this event prevents your team from using it. Its data will still be stored. Are you sure you want to archive this attribute?
This means that while the historical data remains stored in Intercom, the attribute can no longer be updated or used in automation, segmentation, or via the API.
If you have this archived property mapped in your action configuration, the Intercom API will silently ignore it during data submission.
No error will be returned — the API call will succeed, but the archived property will not be updated.
What happens if the property type changes in Intercom?
When changing a custom attribute’s type, Intercom displays a warning:
You may lose some existing values by changing the format.
In practice, Intercom automatically converts existing and newly submitted values to match the new data type. For example:
- If the property was of type float and you change it to integer, sending a value such as
1.4
will result in the value being stored as1
. No validation error or warning is returned by the API.
- If the property was of type boolean and you change it to string, then sending
true
will result in the value being stored as the string"true"
. Again, the API will not return any error.
Essentially, Intercom performs implicit type coercion when property types are modified, without rejecting or warning about mismatched data types.
Attribute type mapping between Revos and Intercom
Intercom supports the following Custom Data Attribute (CDA) types:
- String — text values such as URLs, plan names, or user types
- Number (integer) — whole numbers (e.g.
1
,42
)
- Number (decimal) — numeric values with decimal points (e.g.
1.2
)
- Boolean —
true
orfalse
values
- Timestamp — date and time values (e.g.
converted_at
)
Below is a description of how each Revos field type maps to Intercom attributes.
🧩 String (Intercom)
You can map any Revos field type to a String attribute:
Text
Number
Checkbox
Date
DateTime
Link
All values will be automatically converted to text in Intercom.
Example: a checkbox with value true will be stored as "true" (string).
🔢 Number (integer) (Intercom)
Can be mapped from:
Number
Text
(if it contains a valid integer value)
Example: "123" → 123
🔢 Number (decimal) (Intercom)
Can be mapped from:
Number
Text
(if it contains a valid integer or decimal value)
Example: "1.2" → 1.2
✅ Boolean (Intercom)
Can be mapped from:
Checkbox
Text
(if the value is exactly"true"
or"false"
)
Example: "true" → true
🕓 Timestamp (Intercom)
Can be mapped from:
Date
DateTime
Intercom expects a valid timestamp value (seconds since epoch) or a date-time string that can be parsed into one.
Both date and datetime Revos fields will be correctly recognized as timestamps.
⚙️ Notes and limitations
- Attribute keys are case-sensitive and cannot contain special characters such as
.
,$
,~
,@
,{}
, etc. — unsupported characters will be replaced by underscores.
- String values are limited to 255 characters.
- Arrays, nested objects, or complex JSON values are not supported.
- You can clear a field by sending an empty string (
""
).
- The soft limit for active custom attributes in Intercom is 250.
API limits — how it will be handled
Intercom applies rate limits to protect its API from excessive traffic.
When the limit is reached, Intercom returns a 429 Too Many Requests
response along with rate limit headers:
Header | Description |
X-RateLimit-Limit | Maximum number of requests allowed for the app in the current window. |
X-RateLimit-Remaining | Number of requests remaining before the limit is reached. |
X-RateLimit-Reset | UNIX timestamp indicating when the limit will reset. |
Handling logic in this action
This action includes automatic handling for Intercom API rate limits using axios-retry
.
If Intercom responds with 429 Too Many Requests
, the following will happen:
- The system reads the
X-RateLimit-Reset
header to determine when the limit will reset.
- The request is paused until that time (minimum 2 seconds delay).
- The request is retried automatically — up to 3 attempts.
If the limit persists after all retries, the action fails with an error message from the Intercom API.
TODO:
What will happen if I delete and/or archive this property on intercom?
What will happen if property type on intercom change?
API limits, how it will be handled?
Please describe how each of this attributes will be matched:

Last updated on October 20, 2025