How to Verify Emails Inside Clay With an HTTP API Column

To verify emails inside Clay, add one HTTP API column after your email waterfall, call the SimpleVerifier verify endpoint with GET, read the action field and keep only rows where it equals send. Then you push those rows to Instantly, Smartlead or your CRM. No export and no code are needed.

The recipe is on the Clay template page. This guide gives the exact settings and the reasoning behind them.

What you need

• A Clay table with an email column.
• A SimpleVerifier API key from the API keys page. It starts with sv_live_.

Step 1: add the column

After your last email-finding column, click Add enrichment, choose HTTP API and open Configure.

Step 2: set the request

Use these values:

Setting	Value
Method	GET
Endpoint	https://simpleverifier.com/api/v1/verify?email=/Email
Header	Authorization: Bearer YOUR_SIMPLEVERIFIER_API_KEY

In Clay a forward slash inserts a column into the text. Rename /Email to match the name of your email column. Clay stores the header with the account, so you do not repeat it for each column.

Step 3: choose what to read

From the response, read these fields: status, action, reason and reason_code. The API docs explain each. Add action as its own column so you can filter on it.

Step 4: add a run condition

Set the column to run only when the email column has a value. Empty rows then do not use a call. This matters in a waterfall, where some rows end with no email at all.

Step 5: test on 5 rows

Turn auto-run off. Run the column on 5 rows. Each call can take up to about 30 seconds on a slow mail server, so some rows will take longer than others. Read the results before you run the table.

Step 6: decide what each result does

action	What to do in the waterfall
send	Push to the main campaign.
send_with_care	Put in a separate, capped campaign, or skip.
retry_later	Run the column again later.
do_not_send	Do not push. Try the next finder in the waterfall.

Add a condition so only rows where action is send continue to your sequencer push. Push verified Clay rows to Instantly or Smartlead covers that last step, and export a Clay table to a sequencer covers the CSV route.

Why a waterfall needs its own check

Several finders in a waterfall can each return an address that looks right. A finder returning an address does not mean the mailbox exists. A separate check after the waterfall gives you one independent answer for every row.

Catch-all domains are the hardest case. They accept mail for any address, so a mailbox check cannot prove a person exists there. In the catch-all study, 39.1% of 4,943 sampled business domains accepted a made-up address. SimpleVerifier never marks a catch-all address valid. It comes back as send_with_care. For the Clay side of that problem, see catch-all in a Clay waterfall.

Limits to know

Each key can make 120 calls a minute. Large tables can hit that, so run a big table in batches. See pricing for the API calls each plan includes. If you would rather check a whole table in one go, export the emails and upload the CSV.

Reading the result columns

After the run you will have the original email column plus the fields from the response. Each does a different job:

• status is the plain verdict: valid, risky or invalid.
• action is the machine form of the advice, and the one to filter on.
• reason is a sentence for you to read.
• reason_code is a stable code you can group by, such as a mailbox that exists or a domain with no mail server.

Group your table by reason_code once. If one code dominates, the cause is usually one finder in your waterfall, and you can move that finder lower or drop it.

Common problems

• Every row fails with an authorization error. Check that the header value starts with Bearer and that the key starts with sv_live_.
• A row says the plan does not include API access. That is a 402 answer, so check your plan on the pricing page.
• Rows stop part way through a big table. The key limit is 120 calls a minute, and Clay can run many rows at once. Run the table in batches, or turn auto-run off and run chunks by hand.
• A row is slow. A live mailbox check on a slow mail server can take up to about 30 seconds. That is normal for a few rows.

Where your judgment still matters

The check tells you whether a mailbox accepts mail. It does not tell you whether the person is the right buyer. Keep your own targeting rules. Run the column on one table first and compare the result with what you use today before you switch anything.

If you re-run rows that came back retry_later, see re-running retry_later rows in Clay. For filters on a valid-only table, see Clay filter valid emails only. The older verify emails in Clay post has the broader overview.

Frequently asked questions

Is this a native Clay integration? No. It is the HTTP API column with your own key.

Do I pay Clay credits for the check? Check your Clay plan. The call is billed on your SimpleVerifier plan.

What if a row has no email? The run condition skips it, so no call is used.