Send Embers leads to a Make scenario

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.

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

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

   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.

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

Related