Verify Emails With Make: HTTP Module, Caching and Retries

To verify emails with Make, send each address to a verification API with the HTTP "Make a request" module, parse the JSON, and route on the status field: valid, invalid, or everything else as risky. Add a Retry or Resume error handler so a timeout never reads as a verdict, cache results in a data store so you never pay twice, and size the batch to your credit allowance.

Our Zapier, Make and webhook guide covers single leads at a high level; this is the detailed Make build, for lists as well as new leads. Make behaviour is from its help centre, read on 6 October 2026. The example verifier is ZeroBounce, because its v2 validate docs are public and specific.

The scenario at a glance

Five modules do the work: a source, a cache lookup, the API call, a cache write, and a write-back.

1. Google Sheets > Search Rows, filtered to rows where the status column is empty.
2. Data store > Get a record, keyed on the normalised address.
3. HTTP > Make a request to the verifier, only when the cache has nothing fresh.
4. Data store > Add/replace a record to save the answer.
5. Google Sheets > Update a Row to write status and reason back.

Names are from Make's Google Sheets and data store references. For Airtable or a CRM, swap modules 1 and 5; the middle three do not change.

Step 1: configure the HTTP module

Put the API key and email in query parameters, set Parse response to Yes, and make the module timeout longer than the vendor's. Make's HTTP app documentation lists these fields for "Make a request":

Field	Value for ZeroBounce
URL	https://api.zerobounce.net/v2/validate
Method	GET
Query parameters	api_key = your key, email = {{trim(1.email)}}, timeout = 20
Parse response	Yes
Timeout (advanced)	30
Return error if HTTP request fails (advanced)	Yes

Parse response structures "the output data so that it's easy to map"; without it you need a separate JSON module, another credit per row.

Two timeouts, in the right order. Make's module accepts 1 to 300 seconds. ZeroBounce's timeout accepts 3 to 60, and when reached the API "will return unknown or greylisted". Let the vendor give up first: its unknown is a mappable answer, a Make timeout is an error.

Return error if HTTP request fails makes a 4xx or 5xx raise an error for your handler instead of flowing on as a result. It cannot catch everything: ZeroBounce documents its bad-key and out-of-credits reply as a JSON body, {"error":"Invalid API Key or your account ran out of credits"}, with no HTTP status stated, so the router also checks for an error field.

Step 2: route on the status

Map the vendor's vocabulary to three outcomes, and give the router a fallback route so nothing unexpected is called valid. ZeroBounce returns status as one of valid, invalid, catch-all, unknown, spamtrap, abuse or do_not_mail, in lower case.

Route	Filter	Write to the row
API error	error exists	leave status empty, log the error
Valid	status equal to valid	valid
Invalid	status equal to invalid	invalid
Do not send	status is spamtrap, abuse or do_not_mail	invalid, with the raw status as reason
Fallback	no filter	risky, with the raw status as reason

catch-all and unknown land in the fallback, which is correct: on a catch-all domain the server accepts every address, so nobody outside the company can confirm the mailbox. Write the raw vendor status into a reason column so a vendor change stays traceable; our guide to verification statuses maps the main vocabularies.

Step 3: error handlers, with the 2026 names

Use Retry for transient failures you want re-run, Resume when you would rather mark the row risky and move on, and avoid Skip on a verification step. Make renamed two handlers in May 2026: Break became Retry and Ignore became Skip. Older tutorials use the old names.

• Retry. Make's Retry documentation says it lets you "pause a failed bundle, store the error message, mappings and the remaining scenario flow". With automatic completion on, Make re-runs it on the attempts and interval you set (the page's example: three attempts every 15 minutes). It requires incomplete executions enabled in scenario settings. Use it for a 429 or 5xx.
• Resume. Per Make's docs, it "replaces a failed bundle with a substitute output that you define" and the rest of the scenario runs with it. Substitute status = unknown and the row is written as risky.
• Skip. It "skips the error or the failed bundle" and "marks the scenario run as a success even in case of errors". On a verification step, rows silently stay unverified while the history looks clean.

Step 4: cache results in a data store

Key a data store on the lower-cased, trimmed address, save the status with the date you checked it, and skip the API call when a recent result exists. A re-run or a duplicate lead then costs one lookup, not a paid verification.

Create a data store with fields status (text), reason (text) and checked_at (date). Then:

• Get a record with key {{lower(trim(1.email))}}. Make's text functions define lower() and trim(), which removes spaces at the start and end.
• Add a router. One route, filtered on checked_at later than {{addDays(now; -30)}}, goes straight to Update a Row with the cached status. The fallback route, with no filter, goes to the HTTP module, so addresses with no record get verified. addDays(date; number) accepts a negative number to subtract, per the date functions reference.
• After the HTTP call, Add/replace a record with the same key and "Overwrite an existing record" switched on. Without it, Make's docs say the module throws an error when the key already exists.

Older results should be re-checked; see how often to re-verify a list. Watch storage on small plans: Make allocates data store space as monthly credits divided by 1,000, in MB, so Free gets 1 MB.

Step 5: the credit math before you run it

An action module costs one credit per bundle, so a list costs about four credits per new address in this design. Make's operations page counts one operation per bundle a module processes (its example: Gmail sending 5 emails "= 5 operations"), with triggers the exception at one operation per check, and its credits page says "1 operation equals 1 credit" for non-AI apps.

Module	Credits
Search Rows	1 per run
Get a record	1 per row
HTTP request	1 per uncached row
Add/replace a record	1 per uncached row
Update a Row	1 per row

So 1,000 new rows is roughly 4,001 credits, before router filters (Make's pages do not say whether those consume credits) and before the verifier's own charges. Rows answered from the cache cost two. Make's pricing page lists 1,000 credits a month on Free and 10,000 on the entry paid plans, so a Free account verifies around 250 new addresses a month this way.

Two plan limits matter as much as credits. The Free plan's maximum execution time is 5 minutes. At several seconds per verification, a run that tries a whole sheet will stop part-way, so use the Limit field on Search Rows, which caps how many results Make works with in one execution cycle, to process a batch per run, for example 50 rows.

Step 6: schedule it

Schedule the scenario at a regular interval so each run picks up the next batch of unverified rows. Make's scheduling options include At regular intervals, Daily, Weekly and On demand. The pricing page lists a 15-minute minimum interval and two active scenarios on Free, and a 1-minute minimum on paid plans.

Because Search Rows filters on an empty status, each run takes the next batch and rows that hit an API error are picked up again. For new leads, swap Search Rows for Watch New Rows or a webhook.

When Make is the wrong tool

For a one-off clean of a big list, a bulk CSV upload is cheaper than paying automation credits per row. Make earns its cost on a steady stream of new leads; a backlog is better exported, bulk-verified and re-imported. SimpleVerifier works this way: it takes CSV uploads of up to 100,000 rows on a flat plan and has no public API, so it is not a Make module. Our guide to removing invalid emails from a CSV covers the round trip. To see what one address returns before building, try the free email checker.