Connect Zapier
The easiest way to make something outside Convarza react to something inside it, or the reverse. On every plan.
Before you build anything, decide the direction. Convarza telling Zapier something happened is a different setup from Zapier telling Convarza to do something, and confusing the two wastes an afternoon.
The second decision matters more. Keep the Convarza half in a workflow, not in Zapier. A Zap containing five steps of business logic is invisible to everybody except the person who built it, lives in an account that may be personal, and cannot be read by the team who depend on it. A workflow is three readable blocks with a named owner.
Before you start
- A Zapier account, ideally on a shared team plan rather than somebody's personal one.
- Admin access — integrations and API keys are admin-only.
- A named owner for the integration after it is built.
Steps
Decide the direction first
Out of Convarza, or into it. Write it down as a sentence: "when a lead is created in our website tool, create a contact in Convarza and call them."
Get your credentials from developer options
Under Organisation → Integrations. Admin-only, because an API credential can read and write everything in the workspace.
Generate a key for this integration specifically rather than reusing one. Separate keys mean you can revoke one thing later without breaking everything else.
Connect Convarza in Zapier
Authorise once; the connection is then available to every Zap in that account.
For Zapier into Convarza, use a catch hook
Point the Zap at a workflow catch hook URL and let the workflow do the work. Your team can then read what happens, and the workflow owner is told when it fails.
Keep the Zap thin
Ideally it does one thing: pass the event along. Every piece of logic you put in Zapier instead of a workflow is logic your team cannot see.
Test with one record and look at what arrived
Field mapping is where these break. Confirm the contact was created with the fields you expected, in the right places.
Give the Zap an owner and put it somewhere shared
A Zap in somebody's personal account is a dependency that leaves when they do — and the first anyone knows is when leads stop arriving.
Check it worked
Run it once through the real path. Then deliberately send incomplete data and confirm the workflow declines gracefully rather than creating a half-formed contact.
The parts people get wrong
- Zapier, Make and Integrately are all on every plan, from Starter upwards.
- Zapier retries on failure. If your workflow creates a contact every time it fires, a retry creates a duplicate — make it safe to call twice.
The ones people actually ask
Should the logic live in Zapier or in Convarza?
In Convarza, as a workflow. Point the Zap at a catch hook and let the workflow do the work — then your team can read what happens and the workflow owner is told when it fails. Every piece of logic in Zapier instead is logic your team cannot see.
Our Zap stopped and nobody noticed.
Two likely causes. Zapier disables automations after repeated failures, quietly — log in and look rather than assuming. Or the API key was revoked when somebody left, which breaks every integration built with it and nothing connects those two events for you.
Fields are landing in the wrong places.
Field mapping is where these break. Test with one record and open the contact it created, rather than trusting the Zap history. Use a key dedicated to this integration too, so you can revoke one thing later without breaking everything else.