Make integrationSend every video event to a Make scenario
Zidi posts five events to a webhook you control: a video viewed, a video uploaded, a call-to-action clicked, a campaign launched and a watch threshold reached. Whatever your scenario does next is up to you.
This is the escape hatch for the workflow no packaged integration covers. If the thing you want to happen is not on the list of CRMs Zidi supports natively, a Make scenario gets you there in an afternoon.
How to connect Make
- 1
Add a custom webhook in Make
Create a scenario, add the Custom Webhook module as its trigger and copy the address Make generates for you. It will look like hook.eu2.make.com followed by a long identifier.
- 2
Paste the address into Zidi
Open Integrations in Zidi, choose Make and paste the URL. Zidi checks it belongs to Make and sends a test payload before saving, so a mistyped address is caught while you are still looking at the screen.
- 3
Let Make read the structure
With the test received, Make knows the shape of the data and you can start mapping fields into the rest of your scenario.
There is no Make app to install and nothing to authorise: the webhook address is the whole connection, which is why guarding it matters. Zidi accepts only Make's own hook hosts, in either the make.com or the older integromat.com form, and stores the address encrypted and masked so it is not readable from the interface afterwards. Sending events is on the Zidi Pro plan.
What Zidi sends, and when
| What happens in Zidi | What your scenario receives |
|---|---|
| A video is viewed | An event naming the video and, when the viewer is known, who they are. |
| A video is uploaded | An event marking a new recording arriving in the library, useful for filing or for notifying a reviewer. |
| A call-to-action is clicked | An event recording the strongest signal a video page produces. |
| A campaign is launched | An event confirming the send, which gives your scenario a starting timestamp to measure everything else against. |
| A viewer crosses a watch threshold | An event when someone passes a milestone in a recording, so long videos report progress rather than only the first click. |
Every payload arrives in the same envelope — the event name, a timestamp, an idempotency key and the data — and the key is repeated in the X-Zidi-Idempotency-Key header so a scenario can read it before parsing anything. Deliveries are queued and retried for around twenty minutes if your webhook is unreachable, which is why the key matters: a retry may deliver an event your scenario has already handled.
Build the scenario around the idempotency key
Retries are a feature, and they are also the thing that will bite you. Because Zidi keeps trying for about twenty minutes when a webhook does not answer, a scenario that creates a record on every request can end up creating the same record twice — once for the delivery that timed out on your side after doing its work, and once for the retry. The fix is the value Zidi puts in every payload and every request header: store the idempotency key with whatever you create, and check for it before acting. In Make that is usually a data store lookup at the top of the scenario, which costs one operation and removes an entire class of duplicate. Do this before you build anything that sends email or writes to a system of record.
The envelope is stable, so mapping is a one-time job. Each request carries the event name, the time it happened, the key and a data object, and new event types arrive inside that same shape rather than changing it.
When to use Make, and when to use something else
Reach for a webhook when the destination is yours. An internal database, a spreadsheet your team actually maintains, a support desk, a message into a system nobody has built a connector for — these are the jobs Make is good at, and the five events cover the moments worth reacting to. It is also the right answer when the logic is the interesting part: enrich the viewer, look them up somewhere else, decide who should be told, and only then act.
Reach for something narrower when a packaged path exists. If the destination is one of the CRMs Zidi supports directly, use that integration instead: it writes notes and contacts with matching logic that has already been thought through, and it needs no maintenance from you. If you want the same trigger-and-action model without running a webhook, Zidi is a public app in the Zapier directory with the same five triggers. Make earns its place when neither of those fits.
Make integration questions
Do I need to install anything in Make?
No. The connection is a custom webhook you create inside your own scenario and paste into Zidi, so there is nothing to install and nothing to authorise. If you would rather work with prebuilt triggers than a webhook, Zidi is a public app in the Zapier directory and offers the same five events there.
Which URLs will Zidi accept?
Only Make's own hook hosts, in either the current make.com form or the older integromat.com one. Anything else is rejected when you try to save it. Zidi also sends a test request before storing the address, so a webhook that is not listening yet is caught immediately rather than discovered after your first campaign.
What happens if my scenario is down?
Zidi queues the delivery and retries for roughly twenty minutes. If your scenario comes back within that window it receives the event; if not, the event is dropped from the webhook path, though it remains in your Zidi analytics. Because retries exist, build the scenario to check the idempotency key before it acts.
How do I stop duplicate records?
Use the idempotency key. It is in the payload and repeated in the X-Zidi-Idempotency-Key header, and it stays the same across retries of the same event. Store it alongside whatever your scenario creates and skip any request whose key you have already seen. A data store lookup at the top of the scenario is enough.
Can I send to more than one webhook?
One address is stored per Zidi account. If several systems need the events, point Zidi at a single Make scenario and let that scenario fan out, which also gives you one place to change the routing later.
Which Zidi plan is required?
Pro. The check runs when the webhook is saved, when the test request is sent and again before each delivery, so a workspace that leaves Pro stops sending while keeping the stored address. Returning to Pro resumes deliveries without re-pasting the URL.
Still stuck? Email support@zidi.ai or contact our team.
Other Zidi integrations
CopperPaste a Copper API key and the login email that made it. Recipients become People and engagement is logged as Activities on the contact.
HubSpotCampaign recipients become HubSpot contacts matched by email, and video engagement lands on the contact as five custom properties Zidi creates plus a note.
SalesforceRecipients are matched or created as Contacts; opens, completions and CTA clicks are logged as completed Tasks on the activity timeline.
ZohoConnect any of Zoho CRM's data-centre regions with OAuth. Recipients sync as Contacts and engagement is written as Notes on the contact.
ActiveCampaignConnect with your API URL and key. Recipients sync as Contacts with Notes, and Zidi applies engagement tags such as Watched Video and High Engagement.
CloseConnect Close with OAuth. Recipients are matched by email and video engagement is written as note Activities on the record.
FreshsalesConnect with your Freshsales bundle alias and API key. Recipients sync as Contacts and engagement is written as Notes on the contact.
Monday.comPick a board, paste an API key, and each recipient becomes a board item whose updates record how far they watched and whether they clicked.
ZapierZidi is a public app in the Zapier App Directory, with five triggers: video viewed, video uploaded, CTA clicked, campaign launched and watch threshold.
SlackPost to one Slack channel when a video is viewed, a CTA is clicked, a campaign launches or a viewer crosses 50, 80 or 100 percent.
See every Zidi integration — CRMs, Zapier, Make, Slack, tracking pixels and embed guides.