How to integrate Unify with Intercom
To integrate Unify with Intercom, send an outbound Play webhook to Intercom’s contact API with Bearer authentication and the API host for your workspace region. This example creates a contact from an email address. Contact creation is distinct from starting a conversation, adding a subscription, or launching a messaging workflow.[1][3]
- Connection
- Via webhook
- Customer engagement
- Tool
- Intercom
- Intercom contact
- Data flow
- Unify → Intercom
- JSON payload
At a glance
- Decide how a selected prospect maps to an Intercom contact
- Choose the correct regional destination
- Define the next action separately from contact creation
When this workflow makes sense
Start with the decision your team needs to make, then choose the connection that supports it.
A contact record can provide context for an existing customer engagement process, but the reason for creating it should be clear. Preserve the distinction between a selected prospect, a known product user, and someone enrolled in a messaging program. That makes the handoff interpretable by the team that owns the next action.
A good fit when
Teams already using Intercom and a defined reason to make selected prospect identity available there.
Reconsider the plan when
If the only goal is sending outbound sales email, evaluate the existing sequencing process before creating another contact store.
Design the handoff
Use this framework to agree on the input, the next action, and who owns the result.
Suggested workflow design, based on the documented capabilities below.
| Stage | Decision to make |
|---|---|
| Identity | Decide how a selected prospect maps to an Intercom contact |
| Workspace | Choose the correct regional destination |
| Process | Define the next action separately from contact creation |
| Evidence | Review the stored identity before enabling another automation |
Explore the scenarios
Choose the situation that fits your team and work through the proposed plan.
Open a scenario to explore its plan. Checklists track your selections in this page only.
Prepare a contact for team review
An engagement team needs the identity of a selected prospect.
Create useful context without implying a product signup.
- Choose the workspace
- Send a fictional contact
- Review its role and intended next action
Preserve a known contact
The person already has relationship history in Intercom.
Resolve identity before deciding which fields to change.
- Locate the existing contact
- Define an update-only field set
- Test the update through an owned receiver
Illustrative workflow, not a preconfigured automation. Complete these checks in your own account.
Define success before launch
Inspect the data and the intended outcome separately. Connection status is only the first check.
Expected, not tested
The intended Intercom workspace contains the expected contact identity.
Inspect the contact ID, role, and email. Verify any separately configured messaging process on its own; creation alone does not establish that it ran.
Documentation-based reference. This workflow has not been tested end to end. Use a record or event you control before enabling live activity.
Questions answered
Common decisions when connecting Unify and Intercom.
Does this start an Intercom conversation?
The documented operation creates a contact. A conversation is a separate operation.[3]
Which Intercom host should I use?
Select the API host matching the workspace region.[3]
Can I update an existing contact?
Use the documented update endpoint with the resolved contact ID.[4]
Can I assume every repeated email is a safe upsert?
Use an explicit identity and update policy rather than treating create as that policy.[4]
Will the Intercom ID flow back into my Play?
No. Webhook response data is not passed to later Play steps.[2]
Limits & decisions
Check these boundaries before designing a live workflow around the connection.
- Contact creation does not establish messaging eligibility or subscription
- A reliable create-or-update flow needs identity resolution
- Role and workspace behavior require a controlled account test
- No contact or message was created in Intercom
What the connection supports
Understand the connection, the data involved, and the behavior that matters for a Unify + Intercom workflow.
Technical setup reference
References and requirements for the Intercom connection.
Connection requirements and setup checklist
Before connecting
- A Unify Play with a Webhook action
- An Intercom app token and the correct workspace region
- A policy for new versus existing contacts
Choose the workspace and API version
Use the regional contact endpoint and the version reviewed for your app. This reference uses the documented Intercom-Version: 2.16 header.[3]
Start with a minimal contact
Map an available prospect email into the documented create-contact body. Review the resulting role and identity before adding richer fields.[3]
Handle existing contacts explicitly
For an existing contact, use the update operation with its Intercom ID. Add a receiver when the workflow must search, resolve identity, and choose create versus update.[4]
Request configuration
- Method
POST- URL pattern
https://api.intercom.io/contacts- Headers
Content-Type: application/jsonAuthorization: Bearer YOUR_INTERCOM_TOKENIntercom-Version: 2.16- Authentication
- Use Authorization: Bearer YOUR_INTERCOM_TOKEN for the intended workspace. Select api.intercom.io, api.eu.intercom.io, or api.au.intercom.io for the workspace region.
Choose JSON as the body format. Unify sets Content-Type automatically. The receiver must respond within Unify’s 8-second timeout; request responses are not passed to later Play steps.[2]
Replace URL placeholders with the actual receiver URL from your account or deployed application. These example URLs are not working endpoints.
Example handoff payload
Start with a fictional prospect. Validate the resolved values before using a real record.
Inspect the sample payload and field mapping
{
"email": "avery@example.com"
}Fictional data. Replace sample values before using a real Play.
Minimal fictional contact input. Confirm identity and role in the destination before adding more fields or automations. Use the field mapping to distinguish record data from fixed settings. Select available fields in your Play and inspect Expand preview; do not replace configuration values with prospect data.[2][3]
| Payload field | Value to send |
|---|---|
email | Map the selected email; inspect the resulting contact identity |
The minimal example maps only email. Do not treat a prospect selection as proof of product signup, subscription, or permission to send a message.
Troubleshooting
Start with the stage where the expected data or action stops appearing.
Authorization or region is wrong
Check the app token, workspace region, and matching API host.[3]
The person already exists
Resolve the existing contact and use its ID for an update rather than blindly repeating creation.[4]
A downstream Play needs the contact ID
Track identity in a receiver if later external operations need it. The response body is not forwarded through Unify.[2]
Sources & review
Official documentation reviewed on September 15, 2026.
Technical claims link to primary documentation from Unify and the destination tool. Scenarios, field choices, and recovery plans are editorial implementation examples. Documentation review is separate from execution testing.
Documentation reviewed; end-to-end execution not tested. No named technical reviewer has signed off on these articles yet.
Content updated: . Report a correction to Unify with the tool name, source URL, and behavior you observed.
Keep exploring
