How to integrate Unify with Customer.io
To integrate Unify with Customer.io, send prospect JSON from a Play to a webhook-triggered automation’s generated URL. Map an identifier to Create or Update Person, or create an event for an identified person. Incoming webhook data is the automation’s subject; messaging requires an intentional person-level path.[1][3]
- Connection
- Via webhook
- Customer engagement
- Tool
- Customer.io
- Webhook-triggered automation
- Data flow
- Unify → Customer.io
- JSON payload
At a glance
- Choose the workspace and identifier that select the intended person
- Decide between updating attributes and creating a person event
- Use incoming trigger data for the selected fields
When this workflow makes sense
Start with the decision your team needs to make, then choose the connection that supports it.
A prospect handoff becomes useful when Customer.io can associate the facts with the correct person. Start by choosing the identity and the purpose of the update. Refreshing company context and emitting an event that can start messaging are different business decisions. Keep that choice visible so a routine data refresh does not accidentally become an outreach instruction.
A good fit when
Teams already maintaining customer or prospect profiles in Customer.io and able to define identity and automation ownership.
Reconsider the plan when
If the incoming record has no reliable identifier, resolve that before changing a profile. Avoid using an attribute refresh as an implicit decision to start messaging.
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 | Choose the workspace and identifier that select the intended person |
| Purpose | Decide between updating attributes and creating a person event |
| Mapping | Use incoming trigger data for the selected fields |
| Outcome | Check profile or event changes separately from downstream messages |
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.
Refresh selected prospect attributes
The team wants company context available on an existing profile.
Limit the update to incoming facts and choose the correct identity.
- Select the workspace identifier
- Map the fictional prospect to explicit attributes
- Inspect the matched or newly created profile
Create an event for a separate automation
A qualified handoff should become an event associated with a person.
Choose the event meaning and downstream conditions before enabling it.
- Map the person identifier and event name
- Configure the intended person-level automation conditions
- Test with a controlled identity and inspect both stages
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 fictional input is associated with the intended person and changes only the selected attributes or creates the intended event.
Inspect the person identity, attribute or event values, and downstream automation separately. The webhook does not itself prove that a message was sent to the intended recipient.
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 Customer.io.
How does Unify send prospect data into Customer.io?
POST JSON to the Webhook URL of an automation you create in Customer.io, then map the data to person or event actions.[3]
Does an incoming webhook automatically create a person?
Configure Create or Update Person to do that. Select the workspace identifier and attributes deliberately instead of assuming receipt creates a profile.[3]
Can the webhook automation send the prospect an email directly?
The webhook is driven by data rather than a person. Use an identified person event and a separate messaging automation for the person-level send path described here.[3]
Can I read existing customer attributes in this webhook context?
The documented webhook automation context does not provide existing customer attributes. Use incoming trigger data and design any additional lookup as a separate supported step.[3]
Are Reporting Webhooks the endpoint Unify should call?
No. Customer.io Reporting Webhooks send message activity out to an external receiver. This article uses the incoming webhook-triggered automation path.[5]
Limits & decisions
Check these boundaries before designing a live workflow around the connection.
- Identity must match the actual Customer.io workspace configuration
- Creating or updating a profile is separate from a decision to enroll it in messaging
- Webhook receipt does not demonstrate message delivery or person-level eligibility
- The cited incoming-trigger setup does not specify an extra header-based authentication method
- No person update, event, or message has been sent in a live workspace
What the connection supports
Understand the connection, the data involved, and the behavior that matters for a Unify + Customer.io workflow.
POST / JSON
| Decision | What to know |
|---|---|
| Intake | A generated URL accepts JSON to start a webhook automation[3] |
| Identity | Person and event actions map an identifier from incoming data[3] |
| Updates | Create or Update Person changes a matched person or creates one when unmatched[3] |
| Messaging | An event can trigger a separate person-level automation[4] |
| Context | Webhook-triggered automations use trigger data rather than existing customer context[3] |
Technical setup reference
References and requirements for the Customer.io connection.
Connection requirements and setup checklist
Before connecting
- A Unify Play with a Webhook action
- A Customer.io workspace with permission to create a webhook-triggered automation
- An agreed identifier supported by that workspace, such as email or ID
- An explicit choice between an attribute update and a person-level event
Create the receiving automation
In Customer.io, create an automation with a Webhook trigger and copy the Webhook URL. Send a representative sample so the incoming properties are available during setup.[3]
Associate the data with a person
Choose Create or Update Person when the goal is an attribute update. Select the workspace identifier type and map its value from the trigger data, then explicitly map the attributes you intend to write.[3]
Request configuration
- Method
POST- URL pattern
Paste the generated Customer.io Webhook URL- Headers
Content-Type: application/json- Authentication
- Use the complete Webhook URL generated by Customer.io. The cited setup does not prescribe a separate authentication header for this incoming trigger; this example adds none. Keep the URL private and verify the receiving behavior in your own workspace.
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
{
"event": "prospect_handoff",
"prospect_name": "Alex Morgan",
"prospect_email": "alex@example.com",
"company_name": "Example Company",
"company_domain": "example.com"
}Fictional data. Replace sample values before using a real Play.
The keys are an example handoff format, not required Unify field names. 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]
| Payload field | Value to send |
|---|---|
event | A fixed label you choose for this workflow |
prospect_name | Use {{ person.first_name }} and {{ person.last_name }} for the prospect name |
prospect_email | Use {{ person.email }}; decide how to handle missing values |
company_name | Use {{ company.name }} |
company_domain | Use {{ company.domain }} |
For a workspace using email identifiers, map prospect_email to the selected person identifier and the remaining properties to chosen attributes. Customer.io incoming fields are trigger data. Existing customer attributes are not directly available as context inside a webhook-triggered automation.
Troubleshooting
Start with the stage where the expected data or action stops appearing.
The automation has data but no person to message
A webhook-triggered automation is driven by data rather than a person. Map an identifier and use the documented person or event action to establish the intended person-level path.[3]
A customer attribute is blank in the webhook automation
Use the incoming trigger properties. The documentation states that existing customer attributes are not available as the webhook automation’s person context.[3]
The wrong person changes or receives an event
Check the workspace, identifier type, and mapped identifier value. A static identifier intentionally targets the same person on every run and should not replace the prospect’s identity by accident.[3]
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
