# Send Embers leads to a Make scenario

URL: https://useembers.com/help/integrations/make/
Category: Integrations
Plan: Solo and above
Updated: 2026-09-12
Last verified: 2026-09-12

> Feed a Make custom webhook module from a signed Embers endpoint, then route each qualified lead through a scenario you build.

Make gives you a visual scenario instead of a linear automation, which suits Embers leads well: one branch for high scores, another for everything else, a filter for leads that already have contact details. The connection itself is the same signed HTTPS webhook Embers ships to any receiver.

> **Warning: A recipe, not a native integration**
>
> There is no Embers app in Make's module library. Embers appears in Make as an incoming HTTP request, nothing more. In the Embers app, Make is listed as a recipe on the HTTPS webhook destination under **Settings**, then **Integrations** (`/settings/integrations`). Do not add a second Embers destination for it.

> **Warning: Solo and above, administrators only**
>
> The Integrations and Webhooks screens require Solo or above, and only an account administrator can reach them.

## Before you start

- A Make account that can create a scenario with a custom webhook module.
- A decision about which events you want. Start with new leads only.
- The signing secret from your Embers endpoint if the scenario will verify it.

## Connect Make

### Add a custom webhook module

In Make, start a new scenario and add a custom webhook module as the trigger. Make generates a public HTTPS URL for it. Copy that URL.

### Register the URL in Embers

In the Embers app, open **Developer**, then **Webhooks** (`/developer/webhooks`), and add the Make URL as an endpoint. Give it a name you will recognise in the delivery log six months from now.

Endpoints must be public HTTPS on port 443. URLs containing a `#` fragment are rejected, because browsers never send the fragment part of a URL in an HTTP request. Redirects are not followed, so paste the final URL.

### Subscribe to lead.created

`lead.created` is one event per newly qualified lead and carries the engagement that qualified them, so it is the right starting subscription.

`lead.engagement.added` fires when a lead you already have engages again. It is batched to one event per lead per scan, but it is still the highest-volume event, so new endpoints are not subscribed to it by default.

`lead.status_changed` and `report.generated` are available too if you want the scenario to react to pipeline moves or finished reports.

### Send a sample so Make learns the shape

With the module listening, use the sample send on the Webhooks screen. Embers delivers it with the event type `webhook.test` and `data.is_test` set to true, while the nested lead matches the production event you picked. That lets Make record the structure without a test creating a real record downstream.

### Verify the signature and build the scenario

Check the signature before any module writes data. Embers sends `webhook-id`, `webhook-timestamp`, and `webhook-signature` (`v1,<base64 HMAC-SHA256>`) over `{webhook-id}.{webhook-timestamp}.{raw body}`. See [Verify webhook signatures](/help/integrations/verify-webhook-signatures/).

Then build the rest. Useful fields to route on:

| Field | Why it is useful |
| --- | --- |
| `data.lead.linkedin_urn` | The join key. Vanity URLs change, this does not |
| `data.lead.score` | 0 to 100, the same number the app shows |
| `data.lead.icp_match`, `icp_confidence` | Filter for the strongest matches |
| `data.lead.contact.included` | True only when Embers has a stored email or phone |
| `data.engagement.recent` | Comment text, post URL, and engagement timestamps |
| `account.id`, `account.name` | Route several client accounts through one scenario |

`data.engagement.recent[].engaged_at_precision` tells you whether a timestamp was measured or substituted. LinkedIn publishes exact times for comments and replies but not for reactions. Sequence follow-ups on `exact` rows only.

## What Embers sends and when

A lead is delivered when its score is above zero, it matched your ICP or you approved it manually, and its company is not blocklisted.

Delivery is at least once, and retries can arrive out of order, so use `webhook-id` for idempotency. Accept any `2xx` response quickly and do the slow work after, because a scenario that takes too long to acknowledge looks like a failure to Embers.

## Troubleshooting

**Make stopped receiving.** Check the delivery log on the Webhooks screen. It keeps 30 days of attempts with the state, the error, and the HTTP status of each one.

**The endpoint paused itself.** Any `4xx` other than the retryable set is terminal and pauses immediately. Exhausting the seven retries pauses it too. See [Webhook retries and pauses](/help/integrations/webhook-retries-and-pauses/).

**Names are splitting badly.** The webhook carries `name` only. First and last name exist in the CSV export, HubSpot, and Slack, not here.

## Related

- [Signed webhooks](/help/integrations/webhooks/): Endpoints, events, retries, and the delivery log.

- [Zapier](/help/integrations/zapier/): The same recipe with a Catch Hook.

- [Verify webhook signatures](/help/integrations/verify-webhook-signatures/): Check the HMAC before you trust a request.