How to validate email in Make (formerly Integromat)

Make (the automation platform formerly called Integromat) runs your scenarios on its own servers, which makes it a sound place to check an email address before it reaches your CRM, your mailing list, or a downstream webhook. The catch: there is no native Boundstone module in Make. Not yet — a native integration is planned. Until then you call the API the same way you call any REST service in Make: through the built-in HTTP module. This walks through the whole thing, including the one filter that does most of the work.

Check whether you need an API call at all#

Before you add a module, be honest about the job. If you are validating a single address by hand, use the free keyless email validator — no key, no scenario, no credits. If you only need to reject text that isn't shaped like an email, Make's built-in Text parser (Match pattern) with a simple regex will catch not-an-email before you spend anything.

Those cover syntax. What they can't tell you is whether the domain actually accepts mail, whether it's a throwaway disposable address, or whether it's a role_account like info@ or support@. That is the layer the API adds, and it is the reason to make the call.

There is no Boundstone module — use HTTP "Make a request"#

In your scenario, add the module named HTTP > Make a request. This is Make's generic HTTP client, and it is what every service without a dedicated app gets wired through, Boundstone included. Configure it like this:

• URL — https://api.boundstone.io/v1/verify/email
• Method — POST
• Headers — add one: name Authorization, value Bearer bs_live_YOUR_KEY
• Body type — Raw
• Content type — application/json
• Request content — the JSON below, with the address mapped from an earlier module

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

{{1.email}} is Make's mapping syntax — swap it for whichever field carries the address (a form submission, a new CRM row, a spreadsheet cell). Finally, set Parse response to Yes so Make turns the JSON reply into fields you can map in later modules.

Keep the key in the module, not in the open#

Your bs_live_ key is a server-side secret. Make scenarios run server-side, so pasting it into the module header keeps it off the browser — good. Keep it that way: don't map the key into a field that gets written back to a form, logged to a public channel, or returned in a webhook response. If you call the API from more than one module, store the key once in a Make connection or keychain and reference it, rather than copying the string around.

Read the response and filter on disposable#

A verified address comes back like this:

{
  "valid_syntax": true,
  "domain": "example.com",
  "mx_found": true,
  "disposable": false,
  "role_account": false,
  "free_provider": false,
  "checks": {
    "performed": ["syntax", "mx", "disposable_list", "role_list"],
    "not_performed": ["smtp_mailbox", "catch_all"]
  }
}

Now add a Filter on the link leaving the HTTP module (or a Router if you want to send good and bad addresses down separate paths). The condition that stops most junk:

• Label — Deliverable, not disposable
• Condition — {{2.disposable}} Equal to false
• add a second, ANDed condition: {{2.mx_found}} Equal to true

Anything failing the filter never reaches the modules downstream. If you'd rather sort than block, a Router with two routes — one where disposable is true, one where it's false — lets you log throwaways separately instead of dropping them. The free_provider flag is there too if you want to treat Gmail and Outlook addresses differently; note it is a returned flag, not one of the checks Boundstone ran.

What "valid" actually means here#

The checks object is the point of the whole exercise, so read it before you trust a green result. performed lists exactly what was done: ["syntax", "mx", "disposable_list", "role_list"]. not_performed lists what was not: ["smtp_mailbox", "catch_all"].

That second array is the honest part. Boundstone does not open an SMTP session to knock on the mailbox, and it does not probe for catch-all domains — so it will never tell you a specific inbox exists. It tells you the address is well-formed, the domain accepts mail, and it isn't a known disposable or role address. For gating a signup or cleaning a list, that is usually the decision you needed. When you want more, the not_performed list is your map of what still has to be checked by other means.

The short version#

• There is no native Boundstone app in Make (planned); use HTTP > Make a request.
• POST https://api.boundstone.io/v1/verify/email, header Authorization: Bearer bs_live_..., body Raw / application/json, {"email": "{{mapped}}"}, Parse response Yes.
• Filter on disposable = false (and mx_found = true); use a Router to sort instead of block.
• Keep the bs_live_ key in the module or a connection — never in a client-facing field.
• Read checks.not_performed — ["smtp_mailbox", "catch_all"] — so "valid" means what you think it means.

The same generic-HTTP pattern works in other tools; if you're on a different stack, the n8n walkthrough does this with the HTTP Request node. The full field reference, bulk CSV, and the phone and IP endpoints are in the docs. The free tier is 250 credits a month, no card, and the credits don't expire — enough to wire this up and run it against a real list before you decide anything.