How to verify emails with Make (Integromat)

You can verify emails with Make (formerly Integromat) today, even though there is no branded Qualisend module in the app yet. The pattern is to build a scenario around the generic HTTP module: a trigger fires when a new address arrives, an HTTP request POSTs that address to the Qualisend API, and a Router or Filter reads the verdict and forks the flow — so only deliverable addresses continue on to your ESP or CRM, and risky or undeliverable ones get parked. This guide builds that scenario end to end.

The short answer#

There is no native app to install right now (it is on the roadmap), so the supported pattern is a three-part scenario: a trigger (new form submission, new row, or a custom webhook you point a form at), an HTTP → Make a request module that calls the verification API with the email, and a Router with per-route filters that read the returned status and decide what happens next. Keep your API key in the module's headers — never in a public form field — and set the HTTP module to keep running if the API ever errors, so a transient hiccup never drops a real lead.

Two ways to verify emails with Make#

Before wiring anything up, pick the pattern that matches how fresh the data needs to be:

1. Real-time, per-submission (a scenario). Every new address is verified the moment it arrives and routed on the spot. This is the main subject of this guide and the right choice when the verdict changes what happens next — gating a double opt-in email, tagging a lead, or skipping a fake signup.
2. Batch, after the fact (a CSV). Let submissions pile up in a sheet or your ESP, export them periodically, and run them through a bulk verification job. Simpler, cheaper per address, and a better fit when you just need a clean list before a send rather than an instant decision.

Most teams end up doing both: a scenario on the live intake, plus a monthly list clean to catch addresses that have gone stale since they signed up.

Step 1: the trigger#

Start the scenario with whatever captures the address. Make has hundreds of trigger modules — "Watch Responses" in a forms app, "Watch Rows" in Google Sheets or Airtable, "New Lead" in a CRM. If your form tool has no dedicated Make module, drop in a Custom webhook as the first module and point your form's webhook URL at it; Make generates a unique URL and shows you the incoming data structure as soon as the first submission lands.

Whatever you pick, the important output is a field holding the email address, which later modules reference as a mapped token — Make shows these as coloured pills you click into a field, drawn from the trigger's output bundle. In the examples below that token is written as {{1.email}}, where 1 is the trigger module.

Step 2: POST the address with the HTTP module#

Add a module and choose HTTP → Make a request. This is the step that actually calls Qualisend. Configure it like this:

Turn on Parse response so Make reads the JSON back into mappable fields instead of a raw string. In the Request content box, type the body and drop the trigger's email pill into it:

{ "email": "{{1.email}}" }

The request Make fires on your behalf looks like this — the placeholders are yours to fill in from the developer docs, which list the exact endpoint and show the request in several languages:

POST https://api.qualisend.com/v1/verify
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

{ "email": "jane@example.com" }

Use a scoped key minted for this scenario rather than a full-access key, so if the scenario's execution history ever leaks the key can only verify, nothing else. Never put the key in the form itself or any client-side field — it belongs only in the HTTP module's headers, which run server-side inside Make.

When you click Run once, Make shows the response bundle. You get back a result object holding a status, a reason code, a 0–100 score, and a set of sub_flags. A deliverable address comes back roughly like this:

{
  "result": {
    "status": "deliverable",
    "reason": null,
    "score": 95,
    "sub_flags": { "disposable": false, "role": false, "free": false, "catch_all": false }
  }
}

Those field names are what the next step branches on, so note how Make maps them — you will reference result: status, result: score, and the individual sub_flags in filters. For the full picture of what each status means and how the pipeline arrives at it, see how email verification works.

Step 3: branch on the verdict with a Router#

A verification result you do not act on is wasted credit. The whole point is to route addresses differently, and in Make that is the Router module.

Drop a Router after the HTTP module and it fans out into as many routes as you need. Each route gets its own filter — click the wrench on the line leaving the Router — that tests the parsed status from the HTTP response:

Make evaluates routes left to right and, unless you mark a route as the fallback (the route with no filter), every matching route runs — so keep your conditions mutually exclusive on status to avoid a single address flowing down two branches. Set the undeliverable/no-match branch as the fallback so nothing slips through uncategorised.

You can branch on the sub-flags too. If your product is reputation-sensitive, add a condition to the review route that also fires when sub_flags: disposable equals true, even when the status is otherwise fine — the same call on disposable, role, and free addresses that the role, disposable, and free breakdown walks through. A single Router filter accepts multiple AND/OR conditions, so you can combine a status test and a sub_flags test on one route.

Don't let the HTTP module block a good lead#

One rule matters more than any branch: fail open. If the HTTP module errors — the API is briefly slow, a plan limit is hit, a network blip — you do not want the whole scenario to stop and silently swallow a real signup. Right-click the HTTP module, choose Add error handler, and attach a Resume directive that supplies a default bundle with status set to unknown. The scenario then keeps running down a path that treats the address as "review later" rather than dropping it. (You can also set the scenario's error handling to store incomplete executions so failed runs queue for retry instead of vanishing.)

A verification API is a quality filter, not an authentication gate. Blocking a paying customer because of a transient outage is a far worse outcome than letting one questionable address through and catching it in your next list clean. The same fail-open principle underpins the serverless signup pattern, where a slow probe must never stall the form.

When a scenario is the wrong tool#

Make is glue, and glue has a cost: every verified address burns operations, and a per-submission HTTP call can add up at volume or feel like overkill when you do not need an instant decision. Reach for the batch route instead when:

• You are cleaning a list that already exists — thousands of historical contacts, not new intake. Export them and run a single bulk job.
• Your volume is high enough that per-operation pricing stings, and a nightly or weekly clean is fresh enough.
• You would rather not maintain a live scenario for a task that only needs to run occasionally.

For all three, skip the scenario: export the submissions to CSV from your form tool, sheet, or ESP, and upload that file to Qualisend's bulk verifier. You get the same status, score, and sub-flags per row, downloadable as a cleaned file you can re-import. It is the lowest-effort way to keep a list healthy and your bounce rate down without maintaining any automation.

If you are weighing Make's HTTP approach against calling the API directly from your own backend, the API comparison lays out the trade-offs — a Make scenario wins on speed-to-set-up and needs no server, while a direct integration wins on cost and control at scale. The same HTTP module pattern also ports cleanly to a self-hosted n8n workflow if you outgrow Make's operations pricing.

Frequently asked questions#

Is there a native Qualisend module for Make?#

Not right now. Qualisend's native platform integrations are being rebuilt, so there is no branded app to search for in Make's module list yet — it is on the roadmap. Until it ships, the supported way to verify emails with Make is the generic HTTP → Make a request module pointed at the Qualisend API, exactly as this guide describes. The HTTP approach is also more flexible: you control the request, the headers, and the routing logic.

How many operations does the scenario use per email?#

Roughly one operation per module that runs: the trigger, the HTTP request, and the Router's active route each count. So a single verified submission is a few operations, and 1,000 submissions is a few thousand — well within most paid Make plans. If your volume makes per-operation pricing sting, switch that traffic to the CSV export and bulk-verify route, which uses no operations at all.

Which status should I let through to my email tool?#

Only deliverable for a strict gate. If you want to keep more addresses, allow deliverable plus risky/unknown but route those into a separate, lower-priority segment rather than your main flow — many risky results are catch-all domains that may still deliver. Always reject undeliverable, and consider branching on the disposable sub-flag too if your product is reputation-sensitive.

How do I test the scenario before turning it on?#

Use Make's Run once button with a known-good address and a known-bad one, and watch the bubble on the HTTP module show the returned status — then confirm each Router route lights up for the right input. For quick one-off spot checks outside Make, paste an address into the free email checker and compare the verdict to what your scenario returns.

Ready to build it? Grab a scoped key and the exact request shape from the developer docs, sanity-check any address in the free email checker, and start on the free plan — 100 credits are enough to wire the whole scenario up and watch a bad address get filtered before it ever reaches your list.