Add every qualified lead to a Clay table

Clay is where a lot of teams do the second half of the work: take a person who just showed intent, enrich them, and decide what happens next. Embers can drop each qualified lead into a Clay table as a row, with the score, the ICP verdict, and the engagement that triggered it already attached.

Before you start

• A Clay workspace with room for the rows you are about to add.
• A table to receive the leads. A dedicated table is easier to reason about than a shared one.
• An idea of which enrichments should run on arrival, because they consume Clay credits per row.

Push leads into Clay

1. Create the table and its webhook source

   In Clay, create the table and add an HTTP API source to it, so the table has its own receiving URL. Copy that URL.

2. Register the URL in Embers

   In the Embers app, open Developer, then Webhooks (/developer/webhooks) and add the Clay URL as an endpoint. It must be public HTTPS on port 443, with no # fragment in it.

3. Subscribe to lead.created

   Subscribe to lead.created only. It fires once per newly qualified lead, which maps cleanly to one row per person.

   Leave lead.engagement.added off unless you want a second row every time an existing lead engages again. New endpoints are not subscribed to it by default for exactly that reason.

4. Send a sample and map the columns

   With the source listening, use the sample send on the Webhooks screen. It arrives as webhook.test with the nested lead shaped like a real lead.created, so Clay can build columns from it without a test polluting anything downstream.

   Keep the columns that earn their place:

   Column source	What you get
   data.lead.linkedin_urn	LinkedIn’s immutable member id. Use this as the row key
   data.lead.linkedin_url	The profile link for humans, not for joining
   data.lead.name, title, company	Who they are today
   data.lead.score, icp_match, icp_confidence	The qualification, on a 0 to 100 scale
   data.lead.icp_reason	One sentence explaining the match
   data.lead.top_signals	The signals behind the score
   data.lead.first_seen_at, follower_count	Age of the record, and the divisor for engagement rate
   data.lead.work_history, certifications	Up to 10 entries each, without job descriptions
   data.engagement.recent	Comment text, post URL, author type, and timestamps
   data.lead.contact	Stored email and phone, when included is true

5. Enrich and deduplicate in Clay

   Key the table on linkedin_urn, not on the profile URL. Members change their vanity slug, and some are only ever seen in URN form, so the same person can arrive under two different URLs. Where the URN is blank on an older record, fall back to data.lead.id, the Embers UUID for that account and member pair.

   Then run your Clay enrichments on arrival, or on a filter such as score above 70.

What Embers sends and when

A lead reaches Clay when its score is above zero, it matched your ICP or you approved it manually, and its company is not blocklisted. Blocklisted companies never leave Embers.

Contact fields are a copy of what Embers already stores. The webhook never triggers a fresh lookup, so email and phone are null for anyone not yet enriched, and included is false. That is usually the right division of labour: let Embers hand over the person and the intent, and let Clay do the finding. See Lead enrichment and contact info.

Troubleshooting

Duplicate rows for one person. Delivery is at least once, and retries can arrive out of order. Deduplicate on webhook-id for exact repeats and on linkedin_urn for the person.

Rows arrive with empty enrichment fields. Check data.lead.contact.included before you branch on email. It is true only when a stored value exists.

Deliveries stopped. The endpoint pauses on a 4xx or after the retries are exhausted, roughly 6.3 days after the first attempt. The 30 day delivery log on the Webhooks screen shows which. See Webhook endpoint is paused.

Related