Connect Clay

There is nothing to install. Clay’s built-in HTTP API enrichment can call our API directly, so this is a five-minute setup inside a table you already have. Note the direction: Instantly, Smartlead and HubSpot are where verified addresses go afterwards — Clay is where they get found in the first place.

1. Get an API key

1. In FindLeadEmails, open Developers and create a key under API keys.
2. Copy it straight away — the key is only shown once, and we store a hash rather than the key itself, so it cannot be shown again. If you lose it, create another and delete the old one.

Worth checking the key works before you wire up a whole table. From a terminal:

curl -X POST https://www.findleademails.com/api/v1/email/find \
  -H "content-type: application/json" \
  -H "x-api-key: fle_live_…" \
  -d '{"first_name":"Jane","last_name":"Doe","company_domain":"company.com"}'

2. Add the enrichment in Clay

In your table, click Add enrichment, search for HTTP API, and configure it manually:

1. Method: POST
2. Endpoint: https://www.findleademails.com/api/v1/email/find
3. Headers: x-api-key with your key as the value.
4. Body: the JSON below.

{
  "first_name": "/First Name",
  "last_name": "/Last Name",
  "company_domain": "/Domain"
}

In Clay’s body editor you type / to insert a reference to one of your columns, so those three values become whatever your columns are actually called. Keep the quotes around them — without them the body stops being valid JSON and every row errors.

first_name, last_name and company_domain are all we need. You can also pass company_name and linkedin_url if your table has them; they help in edge cases but are not required.

If you would rather configure the call in Clay’s Query params section than its body, use an inbound webhook instead — that endpoint reads the same fields from the query string, and carries its own token in the URL so there is no header to configure either. The endpoint here needs a JSON body and a header, which Clay handles perfectly well; the query-string route exists for tools that do not.

Keep your key out of the column

A key typed straight into the Headers field is stored as plain text and is readable by anyone with access to that column — including anyone you share or duplicate the table with. Clay’s saved accounts exist for exactly this: store the credential once, reference it from the column, and it stops being visible in the table itself. Use that rather than pasting the key inline, particularly on a table anyone else touches. If a key does end up somewhere it shouldn’t, delete it under Developers and create a new one — that takes effect immediately.

3. Map the response

The fields worth pulling into columns:

1. email — the address, or empty when nothing was found.
2. status — verified, catch_all, predicted, or not_found.
3. confidence — 0 to 1.
4. credits_remaining — handy as a running balance while a big table churns.

Filter on status before you send anything. Only verified means the mail server accepted that mailbox. A catch_all row still comes back with an address, but the domain accepts everything, so nobody can tell whether that specific mailbox exists — and predicted is a pattern match that never got a verdict. Both are useful for research and both are free; neither belongs in a cold sequence unless you have decided to accept the bounce risk.

What it costs

You are charged one credit for a verified result and nothing else. catch_all, not_found, and looking up someone you have already found are all free, so a Clay run over a messy list does not bill you for the misses. Every response carries credits_used and credits_remaining if you want to watch it row by row.

Throughput, and the mistake to avoid

Clay runs rows in parallel, which is the one thing that catches people out. Our API is rate limited per workspace, scaled to your plan:

Buying credits without a subscription earns the same limits as the plan that carries that many credits — a 50,000-credit balance is treated as Volume — so a pack is always spendable at the rate you bought it. If you have both a plan and a balance, you get whichever is higher.

A table of a few thousand rows will still hit the per-second ceiling on the smaller plans. That is not a failure and it never costs you anything — the response is a 429 with a Retry-After header, and nothing is charged for it. But if you leave Clay hammering away, you will collect a column full of errors instead of emails. Two things help: slow the column down in Clay’s own run settings, and size your plan to the table. Every response also carries x-ratelimit-remaining-second, so a custom integration can pace itself precisely rather than discovering the limit by hitting it.

When not to use Clay for this

If you have a list of several thousand people sitting in a CSV, running it through Clay row by row is the slow and expensive way round — you pay Clay credits per row on top of ours, and you are capped by the per-second limit the whole way. Upload the file to Bulk instead, or use the async jobs API, which takes up to 50,000 rows in one call, runs in the background, and is not subject to the per-second limit at all. Clay earns its place when rows are already flowing through a table and you want the address filled in as part of that flow — not as a way to process a list you already have.