Connect Make
For the integrations with branching and multiple steps that a linear Zap makes awkward. Included on every plan.
Make handles branching scenarios more comfortably than a linear Zap, which makes it the right choice when the integration genuinely has decisions in it.
The same principle applies as with Zapier, and applies harder here because Make makes complexity easy: keep the Convarza side thin and put the logic that concerns your team in a workflow where they can read it.
The specific risk with Make is retries. Its error handling will re-run a scenario, and a scenario that creates a contact on every run produces duplicates fast.

Before you start
- A Make account.
- Admin access.
- A deduplication key decided in advance — phone, email, or an external ID.
Steps
Choose Make when the logic branches
If the scenario is linear, Zapier is simpler to maintain. Use Make for the ones with real decisions in them.
Get your credentials from developer options
Admin-only, under Organisation → Integrations.
Use a key dedicated to this scenario. When somebody eventually asks what is calling your API and why, a key per integration is the difference between a one-minute answer and an investigation.
Build the scenario, keeping the Convarza half thin
A catch hook into a workflow. The complexity that belongs to the other system stays in Make; the part that concerns your team lives where they can see it.
Handle errors explicitly
Make will retry. Decide what a retry should do before it happens rather than discovering it as a duplicate problem.
Make writes idempotent
Upsert on a key rather than create. This is the single most important line in this tutorial and the cause of most integration-created duplicates.
Test with deliberately bad data
Missing fields, odd characters, a name in a different script. The happy path always works.
Document what it does, outside Make
Undocumented scenarios are the most common orphaned dependency in any stack. A paragraph in your team's wiki is enough.
Check it worked
Run the same record through twice, deliberately. You should end up with one contact, not two. If you end up with two, fix that before going live rather than after.
The parts people get wrong
- A retry loop hitting a catch hook can create duplicate contacts quickly. Make the workflow tolerant of being called twice.
- All three integration platforms are on every plan. The choice is about how you like to work, not what you are paying.