Skip to main content
Zapier connects DMLY to the thousands of apps Zapier already speaks to: a new contact adds a row to a spreadsheet, a paid invoice posts to your accounting tool, a booked appointment pings a Slack channel. The direction is events out: DMLY pushes events to your Zap the moment they happen, and the Zap does the rest. Zapier and the Webhooks tile are not the same door. Webhooks send events to an endpoint you run; Zapier uses its own subscription handshake: your Zap registers itself with DMLY and shows up in the panel as a connected hook. Use Zapier to reach an app Zapier supports, and Webhooks (or n8n) for your own code.

​
Connect it

1

Generate the API key

Open the Zapier tile on the Integrations page and select Generate API key. The panel then shows two things your Zap will ask for: the API key (behind a Reveal toggle, with Copy next to it) and the Base URL.
2

Build the Zap

The panel’s Setup guide walks you through the Zapier side: create a Zap, choose the trigger app it names, and paste the API key and base URL when Zapier asks you to authenticate.
3

Pick a trigger event

Choose the event the Zap should fire on: a new contact, an inbound message, a paid invoice. Zapier subscribes automatically; there is nothing to configure back in DMLY.
4

Turn the Zap on

A live Zap appears in the panel under Connected Zaps, listed by the event it subscribed to. Turning the Zap off in Zapier unsubscribes it and the row disappears.
The API key is what authorises a Zap to receive your workspace’s events: contact names, phone numbers, message content. Treat it like a password. It is a separate key from your REST API keys: a Zapier key starts zap_ and only works for the Zapier handshake, so it can’t be used to read or change anything else in your workspace.

​
Test it before you rely on it

The panel’s Send a test event section takes an event and sends its sample payload to every Zap connected to this workspace, whatever event each Zap subscribed to (the panel’s own note says only Zaps subscribed to that event, which is not what happens). So a contact.tagged test also runs a payment.succeeded Zap on contact data: pause any Zap whose later steps you don’t want to run before testing. The sample arrives in the same envelope as a real event plus a "test": true field, so you can map its fields into the Zap’s next steps without waiting for a real contact to do something.

​
The events you can subscribe to

The catalogue is the same one the Webhooks tile uses: every topic in Webhook events, from contact.created through appointments, invoices, payments, subscriptions, store events and broadcasts. A Zap subscribes to exactly one event; run several Zaps for several events.

​
What a delivery looks like

Every event reaches the Zap in the same envelope, with the event’s own payload under data:
That example is the sample payload for contact.tagged, what Send a test event delivers (a test delivery also carries "test": true in the envelope). Two fields are worth building around: event tells a multi-purpose Zap what arrived, and id is stable across retries, so deduplicate on it if a step must not run twice.
Zapier deliveries are not signed the way webhook endpoint deliveries are: a Zapier hook URL is an unguessable address that only Zapier and DMLY know, which is Zapier’s own security model for REST hooks.

Webhook events

The full topic list a Zap can subscribe to.

Connect n8n

The same events, delivered to a workflow you run yourself.