How to integrate Unify with Make
To integrate Unify with Make, send a POST request from a Unify Play to a Make Custom webhook. Map the JSON fields into your scenario and choose the routes each prospect should follow. Check the destination result before treating the handoff as complete.[1][3][5]
- Connection
- Via webhook
- Automation
- Tool
- Make
- Custom webhook
- Data flow
- Unify → Make
- JSON payload
At a glance
- Agree on the destination before designing routing rules
- Separate complete prospects from records needing review
- Inspect the destination after webhook acceptance
When this workflow makes sense
Start with the decision your team needs to make, then choose the connection that supports it.
A prospect can be ready for one action and missing the context needed for another. Start by naming the decision: send the record to the intended destination, hold it for review, or do both. Then build the smallest payload that supports that choice. The routing rules should make an incomplete record visible to an owner instead of silently losing it.
A good fit when
Teams using Make to coordinate several destination tools after a prospect reaches a defined stage in a Unify Play.
Reconsider the plan when
If one supported native Unify action already covers the entire handoff, assess whether the extra scenario adds a useful decision or only another place to maintain mappings.
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 |
|---|---|
| Readiness | Define what makes a prospect ready to leave the Play and which fields each destination needs. |
| Routing | Decide whether routes are mutually exclusive or whether the same prospect should reach multiple destinations. |
| Exceptions | Assign a review path for missing or unexpected values. |
| Completion | Check the intended destination and test what a repeated request does before enabling live traffic. |
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.
Route complete prospects to the next tool
A Play selects prospects and Make should send usable records to a destination your team already works in.
Define the required fields before writing filters. A company domain alone should not be treated as a verified person identity.
- Send the fictional payload into the Custom webhook
- Add filters for the chosen destination’s required fields and a fallback for unmatched records
- Test a complete record and one with a missing email
Check a repeated handoff
A request may be retried after a timeout, even though an earlier request already reached the destination.
Choose how the receiving system recognizes a repeat. Sending the same prospect twice should have an intentional result.
- Choose a stable record or event identity available to your workflow
- Define a destination lookup, update, or duplicate check appropriate to that system
- Send the same fictional record twice and inspect both executions
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 prospect follows the intended route and the destination contains the values chosen for the handoff.
Check scenario history and the destination result. The default 200 Accepted response confirms queue acceptance, not successful completion of every module.
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 Make.
How do I connect Unify to Make?
Use a Unify Webhook action to POST JSON to a Make Custom webhook. Configure authentication, send a sample, then map the receiving fields into the chosen scenario action.[3]
Can one prospect follow multiple Make routes?
Yes. A Router processes the matching routes in sequence. Design filters around the actions you intend and use the fallback route for unmatched records.[5]
Does Make require an API key for this webhook?
API key authentication is optional. This example enables it using the x-make-apikey request header.[3]
Does 200 Accepted prove the Make scenario completed?
No. It acknowledges the webhook queue. Review the scenario execution and destination before treating the handoff as complete.[4]
Is this a native connector or a two-way sync?
This design uses the outbound Unify Webhook action. It establishes a Unify → Make handoff; returning data requires a separate supported path.[1]
Limits & decisions
Check these boundaries before designing a live workflow around the connection.
- The scenario and destination actions must be configured in your Make account
- Repeated requests need deliberate duplicate handling in the destination
- Concurrent scenario executions can overlap; use Make’s sequential processing when order matters
- Documentation-based example; no live workflow execution has been performed
What the connection supports
Understand the connection, the data involved, and the behavior that matters for a Unify + Make workflow.
POST / JSON
| Decision | What to know |
|---|---|
| Direction | Unify → Make[1] |
| Receiving step | Custom webhook, POST with JSON[3] |
| Request authentication | Optional API key in x-make-apikey; enabled in this example[3] |
| Routing | Router branches with filters and a fallback route[5] |
| Default response | 200 Accepted acknowledges the queue[4] |
Technical setup reference
References and requirements for the Make connection.
Connection requirements and setup checklist
Before connecting
- A Unify Play with a Webhook action
- A Make scenario and permission to configure its modules
- A chosen destination action and a fictional prospect for testing
Create the entry point
Add Webhooks → Custom webhook to the scenario. Create a webhook, enable API key authentication, and copy the generated URL.[3]
Request configuration
- Method
POST- URL pattern
https://hook.REGION.make.com/YOUR_WEBHOOK_ID- Headers
Content-Type: application/jsonx-make-apikey: YOUR_MAKE_API_KEY- Authentication
- Enable API key authentication in Make and send the key in x-make-apikey. In Unify, use API Key (Header) with that name and the matching secret.
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 }} |
Map the parsed webhook fields into downstream modules. Use Detect new values and resend a sample if a new payload field is missing from the mapping panel.
Troubleshooting
Start with the stage where the expected data or action stops appearing.
Authentication fails
Compare x-make-apikey with the key configured on this webhook. Copy the complete generated URL from the same scenario.[3]
The wrong route runs
Inspect the sample against every filter. A Router can process more than one matching route; use a fallback for data that matches none.[5]
A request is accepted but work is missing
Inspect the queue, scenario schedule, and execution history. An accepted request may still be queued or fail in a later module.[4]
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
