# Add every qualified lead to a Clay table

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

> Push each qualified Embers lead into a Clay table as a new row, keyed on the LinkedIn URN, then enrich and route it inside Clay.

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.

> **Warning: A recipe, not a native integration**
>
> Embers has not built a Clay connector, and Clay has no Embers source to pick from a list. Clay consumes the same signed HTTPS webhook every other receiver does. In the app it appears as a recipe on the HTTPS destination under **Settings**, then **Integrations** (`/settings/integrations`). Do not create 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 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

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

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

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

### 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 |

### 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](/help/outreach/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](/help/troubleshooting/webhook-endpoint-paused/).

## Related

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

- [Webhook payload reference](/help/integrations/webhook-payload-reference/): Every field in every event.

- [Lead enrichment and contact info](/help/outreach/lead-enrichment-and-contact-info/): Where email and phone come from.