Make email verification
Verify emails inside Make scenarios
Add Verifly to Make scenarios through an HTTP request so bad addresses can be filtered before they create CRM records, outbound tasks, or support follow-ups.
GET https://verifly.email/api/v1/verify?email={{email}}
Authorization: Bearer vf_your_api_keyReal-time SMTP mailbox checks
Single, batch, and async bulk verification
Disposable, role account, and catch-all detection
Pay-as-you-go credits with no subscription lock-in
Search fit
Built for Make email verification API searches
Use Verifly when you need a simple API, predictable pricing, and clean JSON results before emails hit your product, CRM, or campaign tool.
Verify in the scenario, route with filters
Make (formerly Integromat) is built around visual scenarios where modules pass a bundle of data from one to the next. Verifly slots in as an HTTP module: it takes the email out of the incoming bundle, checks it live, and enriches the bundle with a deliverability verdict and risk flags that every module after it can read. Because Make parses the JSON response automatically, the result fields become mappable variables you can drop into filters and later modules.
What makes Make especially well suited to verification is its router and filter model. Instead of a binary keep/drop, you add a router after the Verifly module and put a filter on each route: one route for deliverable addresses that flows into your CRM, another for catch-all or role addresses that goes to a review sheet, and a dead-end for undeliverable ones. The verification result becomes a first-class routing signal in the scenario.
Make's operations-based pricing rewards this: verifying once, early, prevents wasted operations on modules that would otherwise process addresses you were always going to discard. And Verifly's pay-as-you-go credits mean the check itself never turns into a fixed monthly cost.
How to wire Verifly into a Make scenario
- After the module that supplies an email (Webhook, form app, Google Sheets), add an HTTP → "Make a request" module.
- Set Method to GET and URL to https://verifly.email/api/v1/verify?email= followed by the mapped email field from the previous bundle.
- Add a header: name Authorization, value Bearer vf_your_api_key. Turn on "Parse response" so Make reads the JSON.
- Add a Router after the HTTP module.
- On each route, set a filter using the parsed result variable: deliverable → main path, catch_all or role → review path, else → stop.
HTTP "Make a request":
URL: https://verifly.email/api/v1/verify?email={{1.email}}
Method: GET
Header: Authorization: Bearer vf_your_api_key
Parse response: Yes
Router filters (using the parsed body):
Route 1 -> {{result}} Equal to deliverable
Route 2 -> {{catch_all}} = true OR {{role}} = true
Route 3 -> fallback (undeliverable): no actionFAQ
Frequently asked questions
Which Make module calls Verifly?
The generic HTTP "Make a request" module. Enable "Parse response" so Make turns the JSON into mappable fields (result, disposable, role, catch_all) for use in later filters and modules.
How do I route contacts by verification result in Make?
Add a Router after the HTTP module and put a filter on each route keyed to the parsed result field — deliverable to your CRM path, catch-all or role to a review path, undeliverable to a dead end.
Will verifying save Make operations?
Often, yes. Checking the email early lets you filter out addresses before downstream modules run, so you don't spend operations processing contacts you'd only delete later.
Where do I put the Verifly API key?
In the Headers section of the HTTP module as Authorization: Bearer vf_your_api_key. Make stores the module configuration with your scenario.
Can I verify lists in bulk from Make?
Yes. Aggregate emails into an array and POST them to /verify/batch from the HTTP module in one call, or for very large jobs use the async bulk pipeline that handles up to 1,000,000 addresses.
How is verification billed for automations?
Pay-as-you-go, $2 per 1,000 checks down to $0.60 per 1,000 at volume, with 100 free credits. There's no subscription, so scenario-driven verification only costs when it actually runs.