Integrate MillionVerifier with Clay
MillionVerifier and Clay integration: build the HTTP API column, run the check, and filter to valid emails before you send. Follow the full setup here.
Clay has no native MillionVerifier integration, but it does not need one. An HTTP API column calls MillionVerifier directly: set the method to GET, paste the verification endpoint with your API key, map your email column into it, and every row comes back with a validity result you can filter on.
This guide walks that setup end to end, then covers what to do with the results.
Why verify emails before sending?
Bounces damage sender reputation faster than almost anything else in cold email. Every invalid address tells inbox providers you do not know who is on your list, and that judgement follows the domain, not the campaign.
Verification is the cheap insurance. It runs between the data source and the sending tool, and it removes the addresses that would have cost you deliverability before they get the chance.
Why MillionVerifier?
We tested it against Debounce, NeverBounce, and ZeroBounce across 50,000 addresses. MillionVerifier was clearly the most accurate of the four on that data.
That is one test on our lists, not a universal law. Accuracy shifts with the shape of your data, so run your own comparison on a sample before standardizing. The workflow below works the same whichever verifier you settle on, since it is just an HTTP call.
How do you get a MillionVerifier API key?
Create an account, then open the API section of the dashboard. You need two things from it:
- Your API key. Treat it like a password. Anyone holding it can spend your credits.
- The single-verification endpoint. Copy it exactly as documented, including the query parameters it expects.
The endpoint takes an API key and an email address and returns that address’s status. That is the whole contract, which is why no middleware is required.
How do you set up the HTTP API column in Clay?
Open the table holding your leads, with the email addresses in their own column. Then add the enrichment.
- Add a new enrichment and choose HTTP API rather than a named integration.
- Set the method to GET. You are retrieving a result, not sending data.
- Paste the endpoint you copied from MillionVerifier.
- Map the email parameter to your email column, so each row substitutes its own address instead of a fixed one.
The mapping step is where this usually goes wrong. If the endpoint still contains the example address from the documentation, every row will verify that same address and return the same answer. Check that the email parameter references your column before you run anything.
How do you test it without burning credits?
Run ten rows first, never the whole table.
A successful call returns a 200 with the address’s status in the body. Failures return an error code instead, which almost always means a malformed endpoint, a bad key, or an unmapped email field rather than a problem at MillionVerifier’s end.
Ten rows costs almost nothing and tells you whether the mapping is right. Running 40,000 rows against a broken endpoint costs real money and tells you the same thing.
How do you use the results?
The response arrives as a JSON object, which is not directly filterable. Hover the result, add the status field as its own column, and name it something plain like Result.
Now the column is usable. Filter to valid addresses only, and send exclusively from that filtered view. Everything else stays in the table for reference without ever reaching a campaign.
This is also the point where verification connects to sending. Once the filter is in place, the same table can push straight into your sequencer, which we cover in connecting Clay to Instantly.
How do you scale this up?
Once the column works on ten rows, it works on all of them, and the pattern generalizes further than email verification.
Any tool with a documented HTTP endpoint can be called from a Clay column the same way. That means enrichment, scoring, and lookups your stack does not natively support can all live in the same table as the leads, without a middleware subscription sitting between them.
The order that matters stays constant: source the leads, verify them, filter to valid, then send. Skipping the middle step is how good copy ends up with a bounce rate that takes the domain down with it. If you would rather not run any of this yourself, our done-for-you cold email service includes the data pipeline as standard.
Frequently asked questions
How do you connect MillionVerifier to Clay?
Use Clay's HTTP API enrichment rather than a native integration. Add an HTTP API column, set the method to GET, paste the MillionVerifier single-verification endpoint with your API key, and map the email parameter to your email column. No Zapier or middleware is needed.
Why verify emails before a cold campaign?
Because bounces damage sender reputation faster than almost anything else you can do. Every invalid address you send to is a signal to inbox providers that you do not know your list. Verification removes those addresses before they can cost you deliverability.
Which email verification tool is most accurate?
We tested MillionVerifier against Debounce, NeverBounce, and ZeroBounce across 50,000 addresses and MillionVerifier was clearly the most accurate of the four in that test. Accuracy varies by list, so test on your own data before standardizing on any one tool.
Do you need Zapier to connect Clay and MillionVerifier?
No. Clay's HTTP API column calls the MillionVerifier endpoint directly, which removes a middleware subscription and a failure point. The only setup is the endpoint URL, your API key, and mapping the email column into the request.